[Infographic] HTTP API Gateway from a serverless perspective

This article was originally posted to Dashbird blog.

Since our latest update, Dashbird also gives you insights into HTTP API Gateway. Let's look at the differences between REST vs. HTTP; HTTP API Gateway pricing, integrations and monitoring.

What is HTTP API Gateway?

Back in the days when AWS released the first version of API Gateway, they tried to make it a higher level than the phalanx of load balancers they already offered. It's serverless and follows a RESTful approach to API modeling, allowing users to use the OpenAPI spec to define their APIs.

While REST is an excellent approach for most APIs, it isn't for everyone, and also, WebSockets were missing from the service. This meant people had to either go with REST and without WebSockets when they wanted a serverless proxy, or they had to go for the application load balancer, which was more low-level but not serverless.

These drawbacks were why they built a new version of API Gateway, called HTTP API Gateway, or API Gateway V2. It comes with the same serverless goodies as automatic scaling and on-demand pricing but offers WebSocket support and isn't bound to REST API design.

AWS HTTP Gateway Infographic by Dashbird

REST vs. HTTP

REST is an API design paradigm created by Roy Fielding. His goal was to give people a tool to design APIs on top of HTTP without all the issues other paradigms like SOAP had in the past. So, REST tries to formalize HTTP to make it more usable for API use-cases.

In turn, HTTP is more flexible; there are other ways to build an API on HTTP that don't follow the REST approach. These include AsyncAPI and GraphQL. In contrast to REST, they have different opinions on endpoint design and using WebSockets to allow real-time interactions.

So, if you're building a simple CRUD API, you can save much time by just going with the REST API Gateway. But if you need to be more flexible, use the HTTP version, but keep in mind that it comes with less help out of the box.

HTTP API Gateway Pricing

API Gateway has a 12-month free tier. That includes these limits for every month:

• one million REST API calls
• one million HTTP API calls
• one million WebSocket API messages
• 750,000 WebSocket API connection minutes

For the first 300 million requests after the free tier, you pay $1 per million; after that, $0.90. 

For the first 1 billion (yes, billion) WebSocket messages, you also pay $1 per million; after that, $0.80 for the next million.

So, the HTTP API Gateway is quite a bit cheaper than the REST version, which costs about $3.50 per one million requests.

Service Integrations

The integration options of the HTTP API Gateway are also a bit limited. While the REST API offers direct integrations with dozens of AWS services, the HTTP version only offers Lambda and HTTP integration. This means if you don't want to integrate with Lambda, your downstream service has to provide an HTTP API.

The Lambda integration is a one-click solution to map a route to a Lambda function; it will automatically forward headers, body, query parameters, etc. Lambda is seen as the default backend for serverless applications, so AWS made its configuration as straightforward as possible.

The HTTP is the catch-all solution. If you want to pipe your requests to another service, HTTP API Gateway will simply proxy it via HTTP. Luckily, you can ensure the downstream service gets the information it needs with parameter mappings.

Authorization

HTTP API Gateway lets you authorize users for your APIs via JSON Web Tokens or an Authorizer Lambda function, which will be called alongside every request. This can get quite expensive; that's why the Lambda response can be cached. All this can be configured; for some APIs, authorization caching isn't an option for security reasons; for others, it might not pose an issue.

The Lambda function can return either a simple boolean value, true for "has access" and false for "doesn't have access," or an IAM document that goes into more detail about what the client is allowed to do. This lets you add authorization features to all your HTTP backends with just a few clicks.

Migrating from REST to HTTP

The whole HTTP approach is more flexible and, what's probably most interesting, it's much cheaper than REST. That alone is perhaps enough to migrate away from the REST version.

But things are different enough between the two that you should consult a migration guide before doing so. The web console looks different; CloudFormation requires you to use other resources, the Lambda integration works differently, etc. 

So, sadly, it isn't just incrementing a version number, adding an HTTP switch, and things are done. But people have already written several articles about this migration and its gotchas. Check out this excellent migration guide from Serverless Guru to get things sorted.

Monitoring HTTP API Gateway with Dashbird

Last month, Dashbird released a big update that includes more services to their monitoring. HTTP API Gateway is one of them. Historically, API Gateway was one of the more expensive parts of serverless architectures, and with Dashbirds new update, you can now get those sweet savings while still maintaining insights.

With the new integration, you can ensure that your gateways won't go down without notice. 

Dashbird gives you the current errors and alerts you when the error percentage rises to a critical level. This includes 4XX and 5XX HTTP errors.

You also get insights into your latency over time and notifications if it increases or is about to hit a timeout.

Last but not least, you get notified of abandoned gateways. That is, gateways you deployed to the cloud, but that aren't used anymore.

Conclusion

HTTP API Gateway is more flexible for non-REST API design and cheaper than the REST version. If you only have a few routes that need to be handled by a Lambda function, it is your best bet.

But HTTP API Gateway integrations are limited to HTTP services, which takes away from that flexibility again. If you see yourself putting Lambda functions between your gateway and your services by the dozen, you might not save any money and raise the complexity of your stack needlessly. That's when you can be better served by a REST API Gateway that offers cheaper integrations to other AWS services.

But independent of HTTP and REST, Dashbird got you covered.

Further reading:

AWS Kinesis vs SNS vs SQS (with Python examples)

Dashbird now integrates with 5 new AWS services

Triggering AWS Lambda with SNS