AWS Services
API Gateway REST API vs HTTP API
Compare Amazon API Gateway REST APIs and HTTP APIs for feature set, cost, authorization, private endpoints, WAF, usage plans, request validation, integrations, and SAA-C03 decisions.
After this, you will understand
API Gateway questions get easier when learners stop treating REST API and HTTP API as synonyms and check the required feature set.
Use HTTP APIs for lower-cost common HTTP APIs; use REST APIs when you need REST-only features such as API keys, usage plans, request validation, caching, WAF integration, or private API endpoints.
Learners choose HTTP API for a REST-only feature or choose REST API by habit when a simple lower-cost HTTP API fits.
Start from the required API management features, not the phrase RESTful API.
Think before readingWhich API Gateway type should you choose when API keys and usage plans are required?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- API Gateway REST APIs
- API Gateway HTTP APIs
- API keys
- Usage plans
- JWT authorizers
- Lambda authorizers
- Private APIs
- WAF integration
- Request validation
- SAA-C03 API Gateway traps
1. Plain-English Mental Model
REST API and HTTP API are both API Gateway products for HTTP-style APIs, but they have different feature sets.
HTTP API = simpler, lower-cost HTTP API features
REST API = broader API management feature set
The exam trick is that "RESTful" as an API style does not automatically mean "API Gateway REST API" as a product choice.
Choose the API type based on required features.
2. Why This Service Exists
API Gateway originally exposed REST APIs with a broad feature set: stages, API keys, usage plans, request validation, caching, private endpoints, WAF integration, transformations, and detailed management features.
HTTP APIs were introduced for common HTTP API use cases with lower cost and simpler configuration. They support many common integrations and authorization patterns, but intentionally do not include every REST API feature.
For SAA-C03, questions often hide the answer in one phrase: "API keys", "usage plan", "private API", "WAF integration", "JWT authorizer", "lower cost", "simple Lambda proxy", or "request validation."
3. The Naive Approach And Where It Breaks
The naive approach is to always pick REST API because the client uses HTTP verbs.
That may work, but it can add unnecessary cost and complexity when HTTP API has the needed features.
The opposite mistake is to always pick HTTP API because it is cheaper. That breaks when the design needs REST API-only features such as API keys, per-client usage plans, API Gateway caching, request validation, AWS WAF integration, or private API endpoints.
Another mistake is to use API keys as authentication. API keys identify clients for usage plans and throttling, but they are not a strong auth mechanism by themselves.
4. Core Primitives
REST API primitives include resources, methods, stages, deployments, usage plans, API keys, authorizers, request validators, gateway responses, caching, mapping templates, and endpoint types.
HTTP API primitives include routes, stages, integrations, JWT authorizers, Lambda authorizers, IAM authorization, CORS configuration, and simpler deployment behavior.
Both can integrate with Lambda and HTTP backends. Both support custom domains and access logs. Feature differences matter.
WebSocket APIs are a separate API Gateway product for bidirectional communication and should not be confused with REST APIs or HTTP APIs.
5. Architecture Use Cases
Use HTTP API for simple serverless APIs where the feature set is sufficient:
client -> HTTP API -> Lambda -> DynamoDB
Use REST API when the API needs API keys, usage plans, request validation, request/response transformations, caching, private APIs, WAF integration, canary releases, or REST-specific management features.
Use JWT authorizers with HTTP APIs when the design fits token-based authorization and does not need REST-only controls.
Use ALB instead of API Gateway when the requirement is ordinary HTTP load balancing for ECS or EC2 without API management features.
Use EventBridge instead of API Gateway when the requirement is asynchronous event routing rather than request/response ingress.
7. Security Model
Both API types support authorization patterns, but details differ.
REST APIs support IAM, resource policies, Cognito authorizers, Lambda authorizers, API keys, private APIs, and AWS WAF integration.
HTTP APIs support IAM, Lambda authorizers, JWT authorizers, and common HTTP authorization needs, but do not support every REST API security and API management feature.
Private API endpoint support is a REST API signal in SAA-C03 style questions.
WAF integration with API Gateway is a REST API signal in AWS's feature comparison. If the design needs WAF at the web edge, CloudFront plus WAF may also be part of the architecture.
8. Reliability And Resilience
Both API types are managed, but backend resilience still matters.
Throttling protects backends from overload. REST APIs have richer per-client usage-plan behavior. HTTP APIs still have account and route-level control patterns, but not usage plans.
REST API caching can reduce backend load for read-heavy APIs where cache correctness is understood.
Use stages and deployment practices carefully. Automatic deployment can be convenient but may not fit controlled release environments.
Monitor 4xx, 5xx, latency, integration latency, and backend errors.
9. Performance And Scaling
HTTP APIs are usually chosen for lower latency and lower cost when the API does not need REST-only features.
REST APIs may add more management features, but those features can be exactly what an enterprise API requires.
Caching can improve read-heavy REST APIs but introduces cache invalidation and stale data concerns.
For high-throughput internal service traffic, compare with ALB or direct service communication.
Backend performance remains the limiting factor when Lambda, containers, or databases are slow.
10. Cost Model
HTTP APIs are designed to be lower cost for common HTTP API workloads.
REST APIs can cost more but include richer API management features.
Caching, WAF, CloudWatch logs, Lambda, data transfer, custom domains, and backend services are part of total cost.
Do not choose REST API just because it sounds more complete. Do not choose HTTP API if a required feature is missing.
12. SAA-C03 Exam Signals
"Lower-cost API Gateway option for simple Lambda HTTP API" points to HTTP API.
"JWT authorizer" often points to HTTP API.
"API keys and usage plans" points to REST API.
"Per-client throttling with usage plans" points to REST API.
"API Gateway caching" points to REST API.
"Private API endpoint" points to REST API.
"Request validation" points to REST API.
"AWS WAF integration with API Gateway" points to REST API.
13. Common Exam Traps
Do not assume RESTful API wording requires API Gateway REST API.
Do not choose HTTP API when the question requires usage plans.
Do not treat API keys as authentication.
Do not forget that WebSocket APIs are separate.
Do not use API Gateway when ALB is enough for simple container load balancing.
Do not use API Gateway for asynchronous event routing when EventBridge is the real fit.
15. Related Topics
Review Amazon API Gateway, AWS Lambda, Serverless API With Lambda And DynamoDB, and CloudFront WAF Protected Web Edge.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.