Service Integrations

Another way is directly integrating the DynamoDB table with the API Gateway and eliminating the middleman, the Lambda function. This approach, though significantly reduces cost and latency, raises a question: How will API Gateway modify the request data according to the DynamoDB table?

Matching the data formats of the client and server is a main concern in service integrations. To address this mismatch, the API gateway maps the requests and responses. Let’s learn how these integrations work.

Integration request and integration response

Integration request is the interface provided by the REST and WebSocket API to map the requests that arrive at the gateway according to the requests expected by the server. Similarly, integration response is the interface used to map the response from the server that arrives at the API Gateway to the response expected by the client.

To understand the mapping of the request or response, it’s necessary to know the parameters of the payload that arrives at the API Gateway. Let’s quickly review the commonly used parameters in a request payload.

• Header value: Headers contain metadata about the request. Header values could include information like the content type, authentication tokens, or any custom metadata associated with the request.

• Query string values: The query string is a part of a URL that contains key-value pairs. It usually starts after the ? symbol and is used to send additional parameters or data to the server.

• Path parameters: Path parameters are placeholders in the URL path that capture specific values. For example, in the URL /users/{userId}, userId is a path parameter.

• Request body: The request body contains the payload of the HTTP request. It sends data to the server, typically in POST or PUT requests.

To transform the data to the desired format, we use Mapping Templates written in VTL. Velocity Template Language (VTL) is a scripting language used within Amazon API Gateway to transform incoming and outgoing requests during the API request/response life cycle. It allows us to customize and manipulate the data being passed between clients and backend services.

Cross-Origin Resource Sharing (CORS)

When working with API Gateways, we may notice a very recurring error:

“Blocked by CORS policy. No Access-Control-Allow-Origin header is present on the requested resource.”

Cross-Origin Resource Sharing (CORS) protection is a feature implemented by most web browsers to safeguard content. It acts as a preventive measure to ensure that a website cannot make unauthorized calls to an API hosted by a different domain.

To achieve this state-of-the-art security methodology, the browser uses an OPTIONS request. This is a preflight request to which the server responds with the values it requires in the header. If the header of the request from the client does not include those headers, the browser does not forward the request to the server.

API Gateway needs to be configured to handle CORS. This involves setting up the appropriate headers in the API’s responses to the preflight and actual requests. If the preflight request is successful and the actual request is allowed, the browser proceeds to make the HTTP request to the API Gateway endpoint.

Example: Integrating DynamoDB with API Gateway

To understand it further, consider the example given above, where we integrate a DynamoDB table with API Gateway. Suppose we have an API Gateway endpoint with the following URL:

This URL gets the Cloud Labs stored on the DynamoDB table. We want to access this endpoint from the web application hosted on https://www.educative.io. To secure our endpoint from attacks, we enable CORS on API Gateway to only allow requests from the URL https://www.educative.io by specifying it in Access-Control-Allow-Origin.

When a user accesses the web application hosted on https://www.educative.io, the browser sends an HTTP request to the /cloudlabs endpoint of our API Gateway. Before making the actual request, the browser first sends a preflight OPTIONS request to check if the actual request is safe to send. API Gateway responds to the preflight request with the CORS headers, indicating that the actual request is allowed. After receiving a successful response to the preflight request, the browser sends the actual request (e.g., GET, POST) to the /cloudlabs endpoint of your API Gateway.