Introduction to Amazon API Gateway

 Amazon API Gateway:

• fully managed service to create, publish, maintain, monitor, and secure APIs at any scale
• APIs act as the "front door" for applications to access data, business logic, or functionality from our backend services
• allows creating:
• RESTful APIs
• optimized for serverless workloads and HTTP backends using HTTP APIs
• they act as triggers for Lambda functions
• HTTP APIs are the best choice for building APIs that only require API proxy functionality
• Use REST APIs if our APIs require in a single solution both:
• API proxy functionality 
• API management features
• WebSocket APIs that enable real-time two-way communication applications
• supports:
• containerized workloads
• serverless workloads
• web applications
• handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including:
• traffic management
• CORS support
• authorization and access control
• throttling
• monitoring
• API version management
• has no minimum fees or startup costs. We pay for the API calls we receive and the amount of data transferred out and, with the API Gateway tiered pricing model, we can reduce our cost as our API usage scales

RESTful APIs

What is the difference between REST API endpoints (apiGateway) and HTTP API endpoints (httpApi)?

The difference between REST API endpoints (apiGateway) and HTTP API endpoints (httpApi) in Amazon API Gateway primarily comes down to features, performance, cost, and use cases.

REST API endpoints (apiGateway):

• Older, feature-rich, supports API keys, usage plans, request/response validation, custom authorizers, and more.
• More configuration options, but higher latency and cost.
• Defined under the provider.apiGateway section and function events: http.

HTTP API endpoints (httpApi):

• Newer, simpler, faster, and cheaper.
• Supports JWT/Lambda authorizers, CORS, and OIDC, but lacks some advanced REST API features.
• Defined under provider.httpApi and function events: httpApi.

Source: ChatGPT

🔧 1. Type & Naming

Feature	REST API (apiGateway)	HTTP API (httpApi)
Name in AWS Console	REST API	HTTP API
API Gateway type	AWS::ApiGateway::RestApi	AWS::ApiGatewayV2::Api
Introduced in	2015	2019

🚀 2. Performance & Cost

Feature	REST API	HTTP API
Performance	Slower	Faster (lower latency)
Pricing	More expensive	~70% cheaper (per request)

✅ 3. Use Cases

Use Case	Best Option
Complex API management	REST API
Lightweight APIs / Webhooks	HTTP API
RESTful applications with full control	REST API
Event-driven APIs, microservices	HTTP API

⚙️ 4. Features

Feature	REST API	HTTP API
AWS Lambda Integration	✅ Yes	✅ Yes
AWS Service Integrations	✅ Yes	⚠️ Limited
VPC Link	✅ Yes	✅ Yes
Request/Response Transformation	✅ Yes (Velocity templates)	❌ Not supported
Usage Plans / API Keys	✅ Yes	❌ Not supported
Caching	✅ Yes	❌ Not supported
WebSocket APIs	❌ (Separate feature)	❌ (Separate feature)
OpenAPI import/export	✅ Full support	✅ Partial support
Mutual TLS	✅ Yes	✅ Yes
Authorizers	Custom & Cognito	Custom & Cognito
Resource-based routing (/users, /users/{id})	✅ Yes	✅ Yes
Fine-grained throttling	✅ Yes	❌ Basic limits only

🧩 5. When to Use Each

✅ Use REST API if:

• We need request/response mapping with Velocity templates

• We need API keys, usage plans, or caching

• We require more granular throttling and resource policies

• We're already heavily invested in REST APIs from earlier architectures

✅ Use HTTP API if:

• We want lower latency and cost

• We only need basic routing and Lambda integration

• We're building new APIs and want simplicity

• We're using JWT/Cognito authorizers with minimal API management overhead

What is API Proxy functionality?

The API proxy functionality in Amazon API Gateway (or APIs in general) refers to a setup where the API Gateway forwards incoming requests to a backend service with little or no transformation. It's like a "pass-through" or "relay" mode.

What is an API Proxy?

An API proxy acts as a lightweight layer between clients and backend services. It receives API calls, forwards them to our backend (like a Lambda, EC2, or HTTP server), and returns the response — often without modifying the request or response.

In AWS API Gateway, this is known as a proxy integration.

Types of Proxy Integrations in API Gateway

• Lambda proxy integration - Sends the full request as-is to a Lambda function. We handle parsing ourself.
• HTTP proxy integration - Forwards the request to an HTTP endpoint (e.g., an internal API) as-is.

Key Characteristics

• No need to define request/response models or mapping templates.
• Backend service gets full access to headers, query params, body, etc.
• The backend is responsible for parsing and responding appropriately.
• Simplifies setup — minimal config in API Gateway.

When to Use API Proxy

Use a proxy integration when:

• We want to quickly expose an internal API to external clients.
• Our backend is already designed to understand HTTP requests directly.
• We don’t need API Gateway to validate, transform, or enrich requests.
• We want to use API Gateway just as a secure, managed front door.

❌ When Not to Use It

Avoid proxies if:

• We need to transform request/response (e.g., mapping formats).
• We want fine-grained access control based on method or path.
• We rely on response caching or usage plans that benefit from richer API Gateway functionality.

Example: HTTP Proxy Integration

Suppose We configure API Gateway like this:

GET https://api.example.com/users

→ forwards to

GET https://internal-service.local/users

If it's a proxy integration, the entire request is passed through — including headers, query params, and body.

In AWS Terms

To configure a proxy integration, We typically:

• Choose Lambda proxy integration or HTTP proxy integration in the console or our IaC tool.
• Avoid defining mapping templates.
• Rely on the backend to parse event (in Lambda) or full HTTP request (for HTTP proxy).

Summary

Feature                         API Proxy

Request transformation No

Full request access          Yes

Use case                         Quick exposure of existing service

Setup complexity         Very low