Supporting Legacy Requests with AWS API Gateway and Lambda

Correct Answer - B.

In this question, the backend Lambda is already upgraded, and the original API is kept for some time.

However, Lambda only supports the new requests without obsolete data in the JSON body, which means that a mapping template is needed to map the original requests to the new ones in Integration Request.

Option A is incorrect: Because the canary deployment in stage configuration can be regarded as a deployment strategy, which does not help support the original requests.

Option B is CORRECT: Because a mapping template can transform the request to the proper format.

From the original users' perspective, nothing has changed.

Option C is incorrect: Because old requests will be blocked by the authorizer.

This is unacceptable.

Option D is incorrect: Because it should be Integration Request instead of Integration Response to add the mapping template.

The correct answer to this question is B. Configure a mapping template in Integration Request to remove the obsolete data so that the original API requests are transformed to be supported by the new Lambda.

Explanation: Since the old API is still being used by some users, it is important to maintain backwards compatibility with the old JSON format. To achieve this, we can use a mapping template in the Integration Request of the API to remove the obsolete data from the request before it is passed to the Lambda function.

A mapping template is a transformation that converts the request or response payload from one format to another. In this case, we can use a mapping template to remove the obsolete data from the JSON body before it is passed to the Lambda function.

To configure the mapping template, follow these steps:

1. Open the API Gateway console and select the API that needs to be modified.
2. Click on the Integration Request of the API.
3. Under Mapping Templates, click on Add mapping template and select the content type of the request.
4. Enter the following code in the template editor:

javascriptCopy code
#set($inputRoot = $input.path('$')) {     "valid_field_1": "$inputRoot.valid_field_1",     "valid_field_2": "$inputRoot.valid_field_2",     ... } 

This code removes the obsolete fields from the JSON body and keeps only the fields that are supported by the new Lambda function.

5. Save the mapping template and deploy the API changes.

With this configuration, the API Gateway will automatically transform the old JSON requests to the new format that is supported by the upgraded Lambda function. This approach allows us to maintain backwards compatibility with the old API while phasing out the obsolete data gradually.

Option A is not a suitable solution since it does not address the problem of maintaining backwards compatibility with the old JSON format. A canary deployment is a useful technique for rolling out new features gradually, but it does not help with transforming the requests to the new format.

Option C is also not a suitable solution since it does not address the problem of removing the obsolete data from the requests. An authorizer is used for controlling access to the API resources based on user authentication, but it does not transform the requests to a new format.

Option D is not a suitable solution since it does not address the problem of transforming the requests to the new format. The Integration Response is used for transforming the response payload from the Lambda function, not the request payload that is sent to the Lambda function.