Less than a year passed since AWS announced a new API type for API Gateway, namely HTTP API. Here I'd like to share my experience with HTTP API utilization.
Since AWS API Gateway has proved its efficiency (especially in serverless architecture), numerous projects adopted this AWS service. Following developers' requests, AWS gave us a chance to have a lighter experience with gateways configurations and support.
But did AWS cut off some of the useful features pursuing simplicity? In my opinion yes. Here are some of them:
1. Pass static data to API target
HTTP API Gateway has cut off the requests modifications on the way from a user to a target. And it seems to be a reasonable simplification. However, it would be very useful to have a way to pass some static data to the target.
For example imagine a scenario, when a target expects an HTTP header which will authorize a request as a one coming from API Gateway. Original API Gateway allowed certification authorization. But this feature is also gone for HTTP APIs.
2. Restrict access to API with policies
Resource policies when applied to API is a great tool for controlling access to the API. It gives the possibility for granular access definition. With several lines with configuration code, we can define which CIDR blocks, VPCs, or AWS accounts are allowed to send requests to the API.
For HTTP APIs it's not available. We are left to JWT, AWS Lambda, or IAM authorizers. They do the job with flying colors, but useless when access should be allowed only for a defined set of IP addresses.
3. AWS CLI interoperability
If you rely on AWS CLI for configurations, you will need to use a new V2 namespace for HTTP APIs. This might look like a pretty minor thing, but for me, it is not.
I rely on IaC modules for setting up an infrastructure. I use Terraform as an engine. With an introduction of the new CLI version, you cannot start using HTTP API just by updating the type attribute in the module definition. You need to describe your API anew.
4. Linking to Load Balancer
To access resources inside a private VPC, a VPC link needs to be defined. Only Application Load Balancers are supported for it. On the other hand, REST API Gateway type can be linked only to Network Load Balancer, which operates on a lower level of OSI model.
If you have NLB already defined, you won't be able to utilize it.
5. Usage plans
Original API Gateway allows configuring usage plans based on a key. You can issue an API key, defined a quota for it, and be sure that the key holder will not abuse your API. That's also not available for HTTP API.
Now let's take a look at some of the pros for HTTP APIs:
1. It's easy to use
To start with HTTP API Gateway, you just need to define a root and integration for it. That's it, you are good to go. No need to define integration requests, responses, etc.
2. It's cheaper
One of the most important selling points for HTTP API presented by Amazon is price:
Most customers will see an average cost saving up to 70%.
Conclusion
If your API is a simple one or you use API Gateway for prototyping, then I would definitely recommend HTTP API.
For production-grade APIs I decided to stick with the original type of API Gateway.
What is your opinion on that?
Top comments (0)