If you are a full-stack developer and need some backend services like cloud server, database or file storage, you must have considered the Amazon Web Services API Gateway, also known as AWS API Gateway.
I have used it for about 2 years on a daily basis. It seamlessly works and generally met my needs.
What does AWS API Gateway do?
For those who have not used AWS API Gateway, I will give you a brief overview.
It stands between clients and other AWS resources and passes clients’ requests to the AWS resources and relays responses from AWS. Generally, it invokes a lambda function that handles AWS resources such as DynamoDB or S3.
While you could use aws-sdk to trigger AWS resources directly on the client-side, it is better to implement AWS resources through AWS Gateway for various security reasons.
2. Four API Types
There are four types of APIs. It seems obvious when to use “Websocket API” and “private REST API”. However, it is hard to tell when to use “HTTP API” or “REST API”. To be honest, even now after a few hours of research , I do not know 100% when to use HTTP API or REST API.
However, if your applications make just regular and simple GET or POST requests to AWS resources, it is safe to say using HTTP API is much better in terms of both pricing and performance.
Let me share my story.
3. My story: migrating from REST API to HTTP API
When I started using API Gateway two years ago, I just “picked” REST API without considering which one is more suited for my cases. I tend to think “makes it work first” and “makes it work better later”.
For two years, I have used REST API without even knowing the existence of HTTP API. As the size of my applications grows, I felt API Gateway is quite expensive. And I looked for a cheaper alternative.
A month ago, I happened to find there is HTTP API, which is about 70% cheaper and 60% faster according to AWS announcements. HTTP API is a relatively new service. It came out in 2020 whereas REST API came out in 2015.
As announced, HTTP API is being offerred in significantly lower prices. As soon as I found out that, I have migrated my API resources from REST API to HTTP API. it actually worked much faster and cheapers. My monthly bill from AWS was significantly decreased and the applications performed better.
4. Who would use REST API?
After migrating to HTTP API, and seeing better performances, I wondered under what circumstances it would be better to use REST API over HTTP API. Why would anyone use REST API if HTTP API is cheaper and faster. There must be something that REST API has and HTTP API does not have.
After digging, I found that there are some features that only REST API has. But it is not that critical at leat to me. I still could not figure out completely. Anyway there are a few features that REST API uniquely has.
- API caching
If you enable the caching option in REST API, the AWS Gateway holds client requests and its corresponding response for a specific period of time, also called TTL(Time-To-Live). And when the client makes the same request, it returns the held response, which improves response timing.
I have done that. The responses definitely come faster, but it cost me significantly more. To me, it is better to use HTTP API without caching than REST API with caching in terms of both pricing and speed.
- Custom parameter transformation & body transformation
In REST API, you can do custom parameter transformation & body transformation using “Velocity Template Language” short for VTL. It is an another language that sets how to parse headers, method, parameters and body passed by clients inside lambda functions. It looks like as follows.
As you see, the language is quite intuitive and not that complicated. However, it is not pleasant to learn another language for such a narrow purpose. Of course, I did not learn. Instead, I just copied and pasted the VTL code someone put on the Stack Overflow to all my API resources.
With the VTL code, parameters are mapped “event.query.paramter1”, “event.query.parameter2”, …. And body is mapped “event.mapped.body1”, “event.mapped.body2” ….. in Lambda functions.
In my case, I really did not need the customization. Even I felt bad whenever I had to copy and paste the VTL to every resource.
- Test Invocation
Unlike HTTP API, you can test to execute API in REST API. It is like the one in Lambda for testing execution.
I barely implemented the test in REST API because most tests were done in Lambda functions.
4.Conclusion
I still believe there must be good reasons why AWS keeps both HTTP and REST. But I failed to find satisfactory answers to that. For a web developer who makes simple and regular GET and POST requests to Lambda functions that handle DynamoDB and S3 objects, I would recommend HTTP API over REST API.
