API development
1. API development
Welcome back! In this section we are going to explore how Amazon API Gateway allows developers to create APIs that expose back-end services.2. API Gateway integrations
API Gateway has a number of back-end integration capabilities. HTTP Integrations allow you to route to any publicly routable HTTP endpoint. Connects an API route directly to an AWS service API (e.g. DynamoDB, SNS). Directly integrate API routes to AWS Lambda functions. You can bridge external clients to privately hosted back-ends using a VPC Link. Mock allows you to generate API Gateway responses by mocking back-end services.3. Integration types: proxy
Integration types can be configured to determine how much control API Gateway has over the request and response. A proxy integration (AWS_PROXY, HTTP_PROXY) passes the entire HTTP request (headers, body, query parameters, and path) directly to the back-end unchanged, with API Gateway acting as a transparent pass-through. The back-end is responsible for constructing a correctly formatted response.4. Integration types: non-proxy
With non-proxy (AWS, HTTP), developers configure request and response transformation using Velocity Template Language (VTL) mapping templates.5. Request validation
API Gateway can validate requests before forwarding them to back-end services. This helps you avoid issues such as missing required fields, invalid JSON format, or incorrect parameter types. Validation failures commonly return 400 Bad Request.6. Request validation
Validation can include: headers, query string parameters, request bodies, and JSON schema validation.7. Request validation
This helps reduce invalid back-end requests, reduce your Lambda execution cost, and improve your API reliability.8. Transformations
API Gateway can transform requests and responses without modifying back-end code. This allows you to change the payload structure, rename fields, transform headers, convert data formats, and hide back-end implementation details. Transformation helps you decouple front-end and back-end systems, maintain backwards compatibility, and support legacy applications. API Gateway uses VTL and mapping templates to do the transformation.9. Handling errors
Errors in API Gateway fall into two categories: gateway errors, generated by API Gateway itself before the request reaches the back-end, and integration errors, returned when the back-end fails or responds incorrectly. Important gateway errors to know about include: 400 Bad Request, which means you have a malformed request or failed request validation. 429 Too Many Requests, means your throttling limit is exceeded.10. Handling errors
Integration errors include: 502 Bad Gateway, Malformed Lambda proxy response (missing statusCode or unstringified body). 503 Service Unavailable, the back-end might be unavailable or overloaded. 504 Gateway Timeout, the back-end exceeded the 29-second integration timeout. This can be extended for Regional REST APIs and private REST APIs.11. Logging
Execution logs and CloudWatch metrics are key troubleshooting tools for API Gateway. API Gateway integrates with Amazon CloudWatch for logs, metrics and execution tracing.12. Logging
CloudWatch logs are commonly used to troubleshoot failed integrations, transformation errors, authentication failures, and Lambda execution issues.13. Stages: managing APIs across environments
A single API definition can serve multiple environments. Stages are the mechanism by which API Gateway manages multiple environments.14. Stages: managing APIs across environments
A stage is a named reference to a deployment snapshot of your API configuration.15. Stages: managing APIs across environments
Common stage names are dev, test, qa, and prod.16. Stages: managing APIs across environments
Stages are reflected in the invoke URL, for example api-id.execute-api.region.amazonaws.com/stage.17. Stages: managing APIs across environments
Stages can reference the same deployment, this helps you achieve instant rollback.18. Stages: managing APIs across environments
Changes to an API do not take effect until explicitly deployed to a stage.19. Stages capabilities
Each stage independently configures the following: Stage Variables are key-value pairs accessible at runtime via ${stageVariables.variableName} as shown in the image. They allow a single API deployment to route to different Lambda functions, aliases, or HTTP endpoints per environment, removing the need to redeploy for environment-specific changes.20. Stages capabilities
Canary Deployments (REST APIs only) route a configurable percentage of traffic to a new deployment alongside the current one. You can promote to full release or delete the canary for instant rollback at any time.21. Stages capabilities
Throttling can be set at stage level, applying across all methods, with per-method overrides available for individual routes.22. Stages capabilities
Caching (REST APIs only, additional cost) stores back-end responses at the stage level. Clients can bypass the cache by sending Cache-Control: max-age=0 when cache invalidation is enabled. The default TTL is 300 seconds, and is configurable between 0 and 3600.23. Stages capabilities
Logging offers two modes: access logs, which use a configurable format built from `$context` variables and are sent to a CloudWatch log group; and execution logs, set to ERROR or INFO level, where INFO captures full request and response detail.24. Let's practice!
Now it's time to put your knowledge of API development on AWS to the test.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.