Application Programming Interfaces (APIs) have become critical to the online and overall business strategies of today’s enterprise. Although on a technical level, many architects would argue that APIs are nothing more than the latest run at the Service-Oriented Architecture (SOA) “holy grail,” the reality is that APIs are an inevitable element to any cloud or mobile initiative. In fact, any organization with a web presence beyond simple marketing content is likely to face business opportunities or demands that require APIs.
Bring Your Own API
APIs are part of the Bring-Your-Own-Everything (BYO*) trend that is driving new requirements into the enterprise based on end-user experiences in the broader consumer Internet. Large public Web companies like Google, Facebook, Twitter, and LinkedIn have robust APIs and strong developer support communities that encourage experimentation and innovative combinations in mash-ups, mobile apps, and cloud solutions. APIs are also a crucial part of cloud infrastructure providers’ strategies, which depend on their self-service models and language-agnostic approach to provide access to the broadest possible market, with the lowest cost of engagement and support.
The consumer Internet and cloud infrastructure are fundamentally public in nature, and not all enterprises can or should embrace this kind of public access. But the core principles of self-service, developer support, and technological independence are driving even the most security-focused and business transaction-oriented enterprises to embrace the culture of APIs.
Enterprise vs. Consumer APIs
Consumer APIs, or “open APIs,” may be catalogued in developer community portals such as ProgrammableWeb to evangelize their broad and open use. By contrast, many of the business-oriented enterprise APIs—which require mission-critical service level agreements, strict privacy controls, strong authentication, business registration requirements, audit and evidential requirements, developer certification, and industry expertise—that are growing out of more traditional businesses are not open to the public.
Often initial thoughts and discussions around new enterprise APIs tend to focus on questions of API design, such as whether to use XML or JSON? HMAC or OAuth? What about resource model? Attribute naming? And more. This can certainly be a challenge and a cultural shift for organizations already supporting APIs based on mature B2B protocols, SOAP, and Web services. But the expectation in the cloud and mobile world is REST and JSON, and while simplistic technical adaptations between protocols are possible, a properly designed REST API, powered by existing data and services, will produce greater rewards in the long run.
Of equal importance to the design of the API is the supporting API management strategy. While some usage patterns of enterprise APIs are similar to those of consumer APIs, tighter controls and narrower developer focus are usually required for enterprise APIs. These two elements are the first of many that make API management a necessity for the enterprise.
There are two critical first steps to get you started with API management.
Step 1: Find the Right People
The first step is to define the participants in your API management landscape. Unlike traditional interactive services focused on end users, the developer groups need to be identified, and possibly segregated—separating internal development staff, registered partners, and customer developers, for example.
APIs need business sponsors or product managers to keep track of costs and pricing (if applicable). The API itself needs developers, along with new online documentation and samples. If you don’t have a discussion group or forum already, it may be worth looking into one to facilitate collaboration between the different developer communities.
Keep in mind that in some ways, you are looking to emulate open API-style engagement with your enterprise APIs. Popular open APIs can provide some inspiration, but the requirements for enterprise API management do impose some constraints.
A major consequence of engaging a broader collection of users is increased demand for identity federation. While single sign-on (SSO) or at least shared credentialing with internal users through LDAP is common, multi-enterprise federation through technologies like SAML or OpenID is more bleeding edge in most enterprises. One possibility is to look to your CRM to manage partner or customer relationships, but you may find that the new personas like developers are not managed through the CRM.
Another option, identity federation in the context of a developer portal, may provide a win-win, giving you the control you need while offering a more engaging experience for the developers you wish to embrace.
Step 2: Put API Management into Action
Once you have found the right people, the second step is to begin an API lifecycle by putting API management into action. With enterprise APIs, much of this involves security mechanisms.
The OAuth v2 standard defines a useful model for API security, whether or not you decide to adopt OAuth. Some of its concepts map onto structures that are likely already exist: resource owners to end users, and resource servers to applications and services. OAuth also assigns credentials to clients, sometimes called API keys, which represent the apps or applications consuming the APIs, which in common practice relates to the developer(s) who created them. You will need a well-defined process for API key management, and supporting policies for issuance, tracking, and revocation.
If your API has a pricing model and/or usage limits, these are often tied to the API key, which begins to link API Management with billing and other financial operations. These integration points are easier to navigate if your API management infrastructure is itself powered by APIs.
Security, Tracking, Visibility
One point of security stress for traditional web application developers embracing API security concepts is the loss of control of sessions. In particular, the standard session inactivity timeout mechanism does not exist in an API. Instead, the application using the API is in charge of defending the API against abuse, which is one reason tracking and revocation are important management facilities.
In place of sessions, OAuth v2 introduces the concept of authorization tokens, including both short-lived access tokens and optional long-lived refresh tokens. Both of these tokens require API management infrastructure, especially in the case of refresh tokens, and again, tracking and revocation are important.
Tracking, instrumentation, and visibility are critical elements for APIs, and not just for security purposes. The instrumentation provided for the API will be the foundation of your billing and monetization plan. Performance tracking and capacity planning are essential to balance your API economics, as usage patterns are notoriously difficult to predict, and you will need quick, if not elastic, reaction times. In addition, throttling and SLA enforcement lie at the intersection of API management and API design, but can be important tools for product management, especially if service levels and tiers are priced.
Finally, you can expect iteration in the API economy, so you will need not only to design the API for versioning, but also to design API management for version control and migration. The architectural approach, which involves segregation of the API technology layer from your classic mainframe, EAI, ESB, SOA or other existing infrastructure, is a good idea. The pace at which your APIs evolve and hit the market will demand a certain level of independence and agility in the business and governance aspects of the APIs, which is where your API management platform plays an essential role.
The introduction of enterprise APIs is in many ways a new business initiative and a new product introduction, and it needs to be managed as such. Product (API) design is an important part of the initiative, but in order to be successful, you must broaden the scope beyond technical design to include all the aspects of API management outlined here. Define clearly the participants in the program, with a special focus on developers. After all, “programming” is an API’s middle name. Also look closely at the runtime management aspects of the API—not only from a security perspective, but also with an outlook of continuous evolution and improvement.
Your enterprise APIs are the gateway between your enterprise and the new Internet economy. The opportunities and risks you face are not necessarily totally technical in nature—your success will hinge on your API management approach.
John Thielens is Axway’s Chief Security Officer, focusing on the secure development and deployment of Axway products and evangelizing security for Axway. With more than 30 years in software development and two decades in the security industry, he has deep hands-on experience with technology, but spends equal energy now blogging and speaking on security and technology topics.