¶ Overview
Allows you to create a public facing REST API that can be used to call things like lambda functions.
- AWS Lambda + API Gateway: No infrastructure to manage
- Support for the WebSocket Protocol
- Handle API versioning (vI, v2...)
- Handle different environments (dev, test, prod...)
- Handle security (Authentication and Authorization)
- Create API keys, handle request throttling
- Swagger / Open API import to quickly define APIs Transform and validate requests and responses
- Generate SDK and API specifications
- Cache API responses
¶ API Types
Rest API
HTTP API
Websocket API Endpoint
¶ Rest API
- Gives you full access to API Gateway features like caching, creating API Keys and Usage Plans
- Integration with other AWS Services
¶ HTTP API
- cheap and designed for low-latency applications
- lacks other API Gateway Features
¶ WebSocket API
- suitable for real-time applications such as chat applications or applications that need a persistent connection.
¶ Integrations
¶ Lambda Function
• Invoke Lambda function
• Easy way to expose REST API backed by AWS Lambda
¶ HTTP
• Expose HTTP endpoints in the backend
• Example: internal HT TP API on premise, Application Load Balancer...
• Why? Add rate limiting, caching, user authentications, API keys, etc...
¶ AWS Service
• Expose any AWS API through the API Gateway?
• Example: start an AWS Step Function workflow, post a message to SQS
• Why? Add authentication, deploy publicly, rate control...
¶ Examples
In this example, you could use the API gateway to allow someone to upload data into S3 using Kinesis Data Streams, Kinesis Firehose and S3 w/out giving anyone access to any AWS services and have it be totally serverless.
¶ API Endpoint Types
¶ Edge-Optimized (default): For global clients
• Requests are routed through the CloudFront Edge locations (improves latency)
• The API Gateway still lives in only one region
¶ Regional:
• For clients within the same region
• Could manually combine with CloudFront (more control over the caching strategies and the distribution)
¶ Private:
• Can only be accessed from your VPC using an interface VPC endpoint (ENI)
• Use a resource policy to define access
¶ Security
¶ User Authentication through
• IAM Roles (useful for internal applications)
• Cognito (identity for external users - example mobile users)
• Custom Authorizer (your own logic)
¶ Custom Domain Name HTTPS security through integration with AWS Certificate Manager (ACM)
• If using Edge-Optimized endpoint, then the certificate must be in us-east-1
• If using Regional endpoint, the certificate must be in the API Gateway region
• Must setup CNAME or A-alias record in Route 53
¶ Resources
- Individual APIs. Think of /hosts, which has put, get, update, delete operagions, /clusters with get, put, delete, ....
- This can also be a parameter used by an API. /clusters/{cluster_name}. cluster_name would be a resource under the /clusters resource.
¶ Lambda Proxy Integration
¶ Lambda Proxy Integration:
- API Gateway passes all the request data (headers, query parameters, request body) directly to the Lambda function.
- The Lambda function then has to handle the request and response generation.
- This gives you more control over the response formatting and allows you to directly manipulate the response in your Lambda function.
- You can modify the status code, headers, and response body before returning it.
¶ Non-Proxy Integration:
- API Gateway transforms the request and response according to the integration setup.
- API Gateway transforms the incoming request into an event object that can be passed as input to the Lambda function.
- API Gateway transforms the response from the Lambda function into the final HTTP response returned to the client.
- With this approach, API Gateway adds some additional structure to the request and response handling, such as mapped request templates and response models.
- This can be more restrictive but may be easier to set up in some cases.
¶ Stages
A name we give to a particular deployment. Version 1, dev, test, prod...