Quick notes: Amazon API Gateway

  • API Gateway is a fully managed service that makes it easy for developers 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 your backend services.
  • You can use API Gateway for building serverless applications, for integrating with legacy applications, or for proxying HTTP requests directly to other AWS services.

3 Basic parts of API Gateway

  1. Request flow: It contains everything the HTTP request hits the backing integration and is concerned with .
  2. Integration: It is outside of API Gateway itself. This is where API Gateway will route your request once it passes authorization and validation. An integration could be:
  3. Response flow: It contains everything the HTTP request hits your integration and deals with .

5 Steps in API Gateway Lifecycle:

1) Protecting your API with Authorization and Usage Plans

  • Authorization is a completely optional step.
  • Using authorization in API Gateway can protect your downstream resources from excess load.
  • You can authorize a request by using Cognito User Pools, AWS IAM, or a Lambda custom authorizer.
  • AWS allows you to configure usage plans. You then associate API keys with a particular usage plan.
  • You can configure API Gateway to provision API keys that must be passed as part of any request. API keys are used for rate limiting and throttling users.
  • With a usage plan, you can configure two things: throttling limits and quota limits. Throttling limits specify how many requests per second are allowed for a particular usage plan. You can use this to prevent a caller from overwhelming your downstream resources. Quota limits allow you to set a maximum number of requests over a particular time period, such as a day, a week, or a month. This allows you to enforce limits on a particular client.

2) Validation with Method Requests

  • The method request step is primarily used for of the incoming request.
  • Validation can be done in two parts.
  • You can validate parameters like querystrings and HTTP headers by specifying the name of the header or querystring.
  • You can validate the request payload (request body) by providing a request model (JSON schema object) against which the request body will be validated.
  • To validate parameters or the request body, you must create a RequestValidator resource.

3) Transforming the request with the Integration Request

  • The integration request step is for data to arrange it in the proper shape for your backend.
  • You can transform the request object by writing mapping templates using the Velocity Template Language (VTL)
  • Mapping templates are configured for a particular Content-Type of the request.
  • When a method request carries a payload and either theContent-Type header does not match any specified mapping template or no mapping template is defined, you can choose to pass the client-supplied request payload through the integration request to the backend without transformation. The process is known as integration passthrough.

4) Handling your response with Integration Responses

  • Integration responses are about the response from your backing integration into something that API Gateway can handle.
  • You use a regex pattern to identify the status code of your response.
  • If you’re using a Lambda integration, the regex pattern is applied to a Lambda error message. If you’re using an HTTP or AWS service proxy integration, the regex pattern is applied to the status code.
  • Once a status code is determined, you may transform the response using a VTL template, just like in the integration request.

5) Standardizing your responses with Method Responses

  • API Gateway only returns a 200 OK status code by default. You can add additional status codes by adding method responses.
  • You need to create the method response your integration response in the previous section (to use a regex to map a particular response to your status code).
  • You can specify models for your response bodies that will help when generating an SDK for a strongly-typed language.