One of the more interesting side effects of the democratization of the API is the rise of the faceless application and the new challenges these applications pose. Whereas organizations used to publish just web pages and Web apps externally, they are now compelled to publish APIs. These APIs can’t take advantage of all the infrastructure that was developed over the years to support Web pages. For example, the browser itself handles a lot of the heavy lifting for client authentication, and there are specialized tools for lifecycle management of web content, optimizing web content delivery, and other common tasks.
All of this changes when you move to APIs. Let’s look at 5 areas of requirements for managing APIs that require a new approach.
- Security: Security is one of the major changes as you move into APIs. In the web app world, authentication is managed by passing security credentials from the browser. Since a human is involved to enter and manage the credentials, and the browser handles the secure channel, it all works pretty well. However with APIs, you’ve got a client application on the other side, and no browser infrastructure to manage secure credential passing. That is why the OAuth standard was created, which provides an easy way to authenticate API requests and works easily with non-website services. Google, Yahoo, Amazon and others had previously created their own protocols for this, but OAuth seems to be the best of all worlds and is emerging to be a more broadly accepted standard.
- Lifecycle Management: In the Web app world, lifecycle management is important to ensure orchestrated rollout of content (and avoid broken links, etc), but it is even more important with APIs. Since applications are the things accessing the APIs, any change will likely break them and potentially cause further reaching damage. Therefore, you need to be even more careful in managing the rollout of API changes. This includes things like making multiple versions of the API available simultaneously to support applications that haven’t “upgraded” to the latest version. While there aren’t many great standards here yet, service registries often provide this capability, and some support RESTful services in addition to the Web services for which they were originally designed.
- Developer Awareness & Support: What good is having an API if nobody knows about it… and how do developers get documentation, authorization keys, and notification of new versions? Unlike Web pages, there is no Google API search (though I suspect that there will be soon – and according to Kin Lane, Swagger may provide the answer). Also, since many companies publishing APIs these days are not software companies, how do they provide support for developers wanting to use the APIs? Online developer resources need to be provided to support these requirements. Though many companies choose to build their own infrastructure for this, increasingly they are turning to API Management solutions like Mashery to fast track these capabilities.
- Operational Monitoring & Control: This is a big area for Websites also, but APIs can’t use the same tools that Websites use. When deploying APIs, companies want to know who is using them and how they are being used. They also want to understand volume and distribution of API requests. This is also critical for billing, when companies want to bill for API usage (which also requires integration with billing applications). In addition, they want to be able to control and throttle access based on the user – potentially even doing things like limiting the number or rate of calls per user, or the times the API is available to specific users. Much of this can be provided from a combination of service registries and service monitoring tools, but many API Management tools also provide some of these functions.
- Performance & Availability Optimization: Performance is always an issue, whether you are dealing with websites or APIs, but often applications are even more sensitive to bottlenecks, and they are certainly more sensitive to outages. Unfortunately, many of the tools and techniques used by Web apps don’t translate directly to APIs. For example, Web page caching is different than data caching for applications, both at the application layer and across the Internet with services like Akamai. So, the appropriate caching and high availability technologies need to be used when you move to APIs.
So clearly as you move into the brave new world of publishing APIs, you need to think differently about your technology, and make some additional investments to ensure that you are doing it right.