

This only really becomes clear if you look in one of two places: Second, the name obfuscates that these are two separate versions of the same technology. I'm at a loss to understand why AWS chose a naming convention that makes them sound like diametric opposites. First off, "HTTP API" is something of an odd naming, given that REST is a framework built on top of the HTTP protocol. However, Amazon sowed a lot of confusion with this "new" API Gateway. A major goal of the change, AWS said, was to simplify the API Gateway model and make it easier to develop and deploy new APIs. This V2 version included support for "HTTP APIs" (effectively REST APIs) as well as WebSocket APIs. Then in 2019, AWS announced that, based on customer feedback, it had developed a new version of API Gateway. These included support for authentication via Cognito user pools, exposing private APIs publicly via VpcLink, and canary deployment support, among many others. Over the next several years, AWS added numerous features to its REST API support. V2: Avoiding A Nasty ShockĪWS released the first version of API Gateway in 2015 with support for REST APIs. I'll also give some proscriptive recommendations around which version to use and when. In this article, I plan to dive a little deeper by discussing some of the ways missing features from one version of API Gateway can be supported in the other. What are the differences? And which one should you use?ĪWS covers the basics of the differences between these two technologies in its documentation.

However, AWS currently supports two very different versions of the technology. AWS API Gateway is a great technology for managing and securing access to your backend REST APIs.
