REST API Notes for 2015/07/16 - AMAZON GATEWAY EDITION

Last week many within the API community were pleasantly surprised by the Amazon API Gateway. Promising to provide a "scalable" and "secure" entry point for API services, many (me included), instantly assumed this was Amazon's entry into 'API Management'. Amazon's introduction, however, oddly omits the term. Even some industry 'reporting' seemed confused. There are already numerous API Management providers - 3Scale (who quickly responded to the news), Apigee, Akana, Axway (who also responded), Layer 7, Mashape, Mashery, StrongLoop, etc. Should Amazon's Gateway be considered a competitor?

An API Management provider should provide a number of features, including Analytics and Traffic Management. They also come in different configurations. Some, like Apigee, are proxies the funnel all traffic between a company and the end users through them. Agents are pieces of code that "plug" into existing server configurations. Rather than sitting in front of a server, their code runs on the server, effectively becoming part of the deployment. Finally, hybrids are combinations of both approaches. This is a situation where a proxy is deployed local to the API server, but the administrative console and API management activities remain "in the cloud".

Early evaluations of Amazon API Gateway have been mixed. There's lots to like. However, stating that it is a true API Management solution appears premature. As Alexei Balaganski says:

"There seems to be no developer portal functionality provided with the service at the moment. Although it is possible to create API keys for third-party developers, there is no self-service for that. In this regard, the service does not seem to be very suitable for public APIs."

The Hiram Software Blog puts it more bluntly:

"...the Amazon API Gateway is not yet ready to handle requests where your code wants to read from both the metadata (headers, path parameters, and query parameters) and the request body. It also is not yet ready to handle authentication based on IAM, despite what the advertising says."

If not supporting efficient transfer of essential API attributes like headers and query parameters seems outrageous, it is because it is. But before we shrug and move on to whenever Amazon Gateway gets patched, it is important to note the Lambda aspect to all this. John Titus concludes his excellent walk through like this:

"That’s it — a website and an API without any web servers."

For all the excitement that Docker and containers generate, they are an evolutionary spin on having an OS spun up, somewhere, listening for requests. Amazon itself has done the yeoman's work of getting developers comfortable with the idea of scaling machines up and down based on resource load. Lambda goes further because there is no server. A request comes in, stored code is executed, and a response goes out. The Amazon Gateway is significant because it allows developers to simply tie HTTP requests to Lambda functionality. That's both a validation of how important REST based APIs are (Amazon is providing a proxy to Lambda that speaks REST) and an unlocking of post-server potential (the care taken to make Lambda a launch area of emphasis).

Should existing API Management customers flock to Amazon Gateway? Early results suggest no, unless your already using Amazon Lambda. But it will be fascinating to see where Amazon goes from here.