[Infographic] HTTP API Gateway from a serverless perspective

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.

Read our blog

5 Common Amazon SQS Issues

As with all services on AWS, issues can crop up while using SQS because it’s not always obvious what every service can and cannot do. But fear not, for this article aims to help you solve the most common ones as quickly as possible. Ready to fix your queues? Then let’s dive in!

5 Common Step Function Issues

Here you will find the most common issues when working with Step Functions, especially when starting with the service.

6 Common DynamoDB Issues

It’s expected that developers face many of the same issues when starting their NoSQL journey with DynamoDB. This article might clear things up a bit.

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.