I was recently looking into API Gateways for a project. As I was reading up on AWS’ API Gateway, I realized that there were two options that I could potentially choose: REST APIs or HTTP APIs. The two services had similar names and provided similar features and left me feeling pretty confused about which option was more suitable for my use-case.
One can always count on AWS to create new products that end up confusing people even more. As I started digging deeper to understand the differences, I wondered why Amazon created an entirely new HTTP API service instead of improving the existing REST API service. This way the customers get all the benefits and don’t have to spend time trying to understand the differences and choosing the right service for themselves.
In this article, I’ll try and do a comparison between the two services, and hopefully, that will be useful for folks who are trying to decide between the two services.
API Gateway is a managed service that makes it easier to manage the APIs (creating, publishing, and maintaining secure APIs). API gateway has become one of the pillars of the microservices and serverless architectures.
This article is a great resource for learning more about API Gateway.
HTTP & REST APIs
The first version of API Gateway was introduced in 2015. The first version of the API Gateway is referred to as REST APIs which is probably the most common usage of the API Gateway.
During re:invent in 2019, Amazon introduced a new flavor of the API Gateway, called HTTP APIs. HTTP APIs were designed from the ground up and thus, are supposed to be faster and cheaper than REST APIs.
The tables below show the pricing for both HTTP & REST APIs for the us-east-1 region. As shown below, HTTP APIs are significantly cheaper than REST APIs.
|Number of requests(per month)
|First 333 million
|Next 667 million
|Number of requests(per month)
|First 300 million
In their announcement, AWS claimed that HTTP APIs are up to 60% faster than REST APIs. I spun up a simple service to compare the performance for myself. To mimic a somewhat realistic scenario, my service makes a call to DynamoDB and an external third party API. From my tests, it seems like AWS’ claims about HTTP APIs being faster does hold up.
There is a lot of feature disparity between the two offerings and its helpful to look at these differences to understand which service is more suitable for one’s requirements.
I have tried to summarize some of the critical differences between the two services below (as of Sep 2020). AWS is actively working on getting HTTP APIs to feature parity with REST APIs, so the list below might change in the future.
Both HTTP and REST APIs support Account-level throttling. By default, API Gateway limits the steady-state request rate to 10,000 requests per second (rps). REST APIs also support usage plans with API keys which can be helpful if you need to throttle at an individual API key level.
AWS Web Application Firewall (WAF) can also be integrated with the REST APIs to provide additional protection from attacks.
HTTP APIs don’t support the ability to cache endpoint responses whereas REST APIs provide this functionality.
AWS X-Ray can be used to trace requests made via REST APIs whereas this functionality isn’t supported for HTTP APIs.
API Gateway supports three different endpoints types:
- Edge-optimized: Ideal for geographically distributed clients
- Regional: Intended for clients in the same AWS region
- Private: can only be accessed from your AWS VPC
Currently, HTTP APIs only support the Regional endpoint type.
REST APIs currently support request validation whereas HTTP APIs don’t.
This page from AWS lists all of the differences between the two services.
As of Sep 2020, the main reason to use HTTP APIs seems to be the cost. However, if your APIs need any of the features not yet supported by the HTTP APIs, using the REST APIs will be your best bet. AWS has already built tools that make migrating APIs from REST to HTTP easy, so it will hopefully be straightforward to migrate your APIs in the future.