The strength and success of the Cyrex Enterprise team comes from its people, the individuals who bring our clients the success and security they’re looking for. One of our many talented members is Luccas de Barros who has been sharing some of his personal tech thoughts and measures. We wanted to highlight some of his work as both a benefit to those interested and to show off a little! First up, a look at AWS and the contest between REST API and HTTP API!
Introduction
The first question we need to ask is: when should we use REST API, and when should we go for HTTP API? What are the advantages and disadvantages of each?
Recently, I found myself in a situation where I had to take a more simplified approach—in other words, making a trade-off based on the context I was dealing with.
Context
The system was already using a REST API, and when developing a new one, I wanted to reuse the same authentication flow. Naturally, I considered using Auth0. However, the problem was that my REST API was integrated with a custom Lambda authorizer, making authentication a bit more complex. I didn’t want that.
That’s when I faced a dilemma: how could I reuse my existing setup without introducing unnecessary complexity?
The Solution: HTTP API
Comparison: REST API vs. HTTP API
In AWS, both REST APIs and HTTP APIs are solutions for exposing services through API Gateway, but they have significant differences:
- REST APIs offer a more feature-rich set, including API keys, rate limiting, AWS WAF integration, and private endpoints.
- HTTP APIs are a lighter and more cost-effective alternative, focused on simplicity and performance—ideal for scenarios where advanced features are unnecessary.
When it comes to management and monitoring, REST APIs provide greater control with features like caching, detailed execution logs, and AWS X-Ray tracing. HTTP APIs, on the other hand, are more limited but allow automatic deployments and private integrations with Application Load Balancers and AWS Cloud Map, which REST APIs do not support.
REST APIs provide more tools and configurations, but that doesn’t always mean we need them—otherwise, we risk overengineering.
One Key Advantage of HTTP API: Built-in JWT Authentication
This was the feature that caught my attention. I found the solution to my problem right here. Now, it was just a matter of implementation.
Hands-On
Step 1 – Creating the Auth0 Application
The first step is always to create your application in the Auth0 dashboard. In this case, I’m creating a Single Page Application (SPA), as it makes the most sense for the project—since login redirects and authentication handling will happen on the frontend.
📌 Note: This article skips some how-to steps to keep things simple. If you’re already familiar with AWS and Auth0, the process should be intuitive.
Dashboard > Applications > Applications
Once the SPA is created, we get the credentials we need for integration.
Generated Data When Creating SPA Application in Auth0
Step 2 – Creating the HTTP API in AWS SAM
With my SPA set up, beyond integrating domain redirects on the frontend, the next step is authenticating our API Gateway routes.
In this setup, I’m using AWS SAM (Serverless Application Model), an extension of CloudFormation that simplifies the creation and management of serverless applications.
📌 Key point: The API definition is handled through an OpenAPI (OAS) YAML file, meaning all configurations related to endpoints, methods, responses, and authentication are defined within the openapi.yaml
file.
Template Model to Create/Deploy HTTP API in AWS
Step 3 – Authenticating the Routes
This step is straightforward—just a few specific AWS configurations to set up authentication for our routes.
The API Gateway OpenAPI Template
Although I’m handling CORS configurations both here and in AWS SAM, I wanted to highlight that it’s also possible to configure some API settings directly in openapi.yaml
.
Where the Simplicity Comes In
By adding our audience and issuer (both generated when creating the SPA in Auth0), the HTTP API automatically integrates Auth0 authentication into our routes.
Of course, this assumes pre-configured users and authentication flows in Auth0, but the key takeaway here is how something that initially seemed complex became extremely simple.
From this point on, any new route added that is tied to our security schema will automatically have authentication configured—no extra effort needed.
Final Thoughts
When choosing between REST API and HTTP API in AWS, it all comes down to your needs. REST APIs provide extensive control and features, but in many cases, they introduce unnecessary complexity. HTTP APIs, on the other hand, offer a simpler, faster, and cost-effective approach, especially when combined with built-in JWT authentication, as seen with Auth0.
For my use case, the trade-off was worth it—I simplified authentication without compromising security, and everything worked seamlessly.
🚀 When simplicity meets efficiency, great solutions emerge!
Thanks Luccas! We’re always pleased by the thoroughness and skill shown by our staff. If you’re interested in leveraging some of our software development or load testing expertise like that shown by just one of our team here, get in touch today! Don’t forget to keep up with Luccas and his LinkedIn postings here!
Related Articles

Reflecting on 2024: A Year of Growth, Innovation, and Milestones
Reflect on 2024 with Cyrex Enterprise! Discover our achievements in software development, ...
Read more
Deploying NestJS Microservices to AWS ECS with Pulumi IaC
Let’s see how we can deploy NestJS microservices with multiple environments to ECS using...
Read more
What is CI/CD? A Guide to Continuous Integration & Continuous Delivery
Learn how CI/CD can improve code quality, enhance collaboration, and accelerate time-to-ma...
Read more
Build a Powerful Q&A Bot with LLama3, LangChain & Supabase (Local Setup)
Harness the power of LLama3 with LangChain & Supabase to create a smart Q&A bot. This guid...
Read more