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 and on-demand pricing but offers and . automatic scaling WebSocket support 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 to get things sorted. migration guide from Serverless Guru Monitoring HTTP API Gateway with Dashbird Last month, Dashbird that includes more services to their monitoring. HTTP API Gateway is one of them. Historically, 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. released a big update API Gateway 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.

Alongside

Amazon

Phalanx

OpenSearch From a Serverless Perspective

You’ve Been Thinking of Serverless All Wrong!

Serverless af

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Devops

Nominated for 2022 - HackerNoon Contributor of the Year - Serverless

Nominated for 2022 - HackerNoon Contributor of the Year - Aws

Too Long; Didn't Read

A Serverless Perspective on HTTP API Gateway 

A Serverless Perspective on HTTP API Gateway

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Things in Engineering We Don't Spend Enough Time On

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 1)

10 Things in Engineering We Don't Spend Enough Time On

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 1)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps