Configuring the API Gateway Backend

Introduction

In this step, you will update the API Gateway Integration Request from Mock to AWS Lambda. You will map both API endpoints to the same Lambda function.

Instructions

1. Return to the API Gateway console and select /items > GET method:

2. Click Integration Request and set the following values:

• Integration type: Lambda Function
• Use Lambda Proxy integration: unchecked
• Lambda Region: us-west-2 
• Lambda Function: ItemsFunction

Remember, when you simply select the Lambda Function name, API Gateway will use its $LATEST version. Using $LATEST is generally not recommended since you always want to bind your API Resources to stable Lambda aliases (dev, stage, etc.). The next instruction shows how to map each API Gateway stage to the correct Lambda alias.

3. Add :dev to the end of the Lambda Function to use the dev alias. The complete value is ItemsFunction:dev:

4. Click Save and click OK in the Switch to Lambda integration modal that appears.

5. Click OK to grant API Gateway permission to the Lambda function (alias):

This is required because, by default, nobody can invoke your Lambda functions unless you grant the right IAM permission. If you configure API Gateway via the Console, this operation will be automatically performed by AWS.

6. Click the pencil icon to the right of the Lambda Function to edit its value to ItemsFunction:prod:

You are changing the value to give API Gateway permission to the prod alias as well as the dev alias.

7. Click the check mark icon and click OK in the Add Permission to Lambda Function modal:

You will now do similar actions for the /items/{ID} resource.

8. Select the /items > GET > /{ID} > GET method.

9. Click Integration Request and set the following values:

• Integration type: Lambda Function
• Use Lambda Proxy integration: unchecked
• Lambda Region: us-west-2 
• Lambda Function: ItemsFunction:dev
• Mapping Templates:
  • Request body passthrough: When there are no templates defined

This time you need to configure the Mapping Templates because the resource includes a dynamic {ID} variable. You will map the ID path parameter to a Lambda event parameter, via a custom mapping template.

10. Click on application/json and scroll down to the template editor and overwrite the default contents with the following and click Save below the editor:

Copy code
{
  "ID": $input.params("ID")
}

11. Click Save above the Mapping Templates section and click OK in both the Switch to Lambda integration and Add Permission to Lambda Function modals that appears.

12. Click the pencil icon to the right of the Lambda Function to edit its value to ItemsFunction:prod:

13. Click the checkmark icon and click OK in the Add Permission to Lambda Function modal.

At this point, all the API Gateway Resources can access both Lambda Aliases and we won't need to manually grant any additional permission. You now need to re-deploy the API into the prod stage.

14. Click Actions > Deploy API and select the prod Deployment stage before clicking Deploy.

If everything went fine, the same endpoint will finally return real data from the Lambda function, instead of fake data.

In theory, you'd need to deploy the dev-configured Resources into the dev Stage and the prod-configured resources into the prod Stage. For now, you can just deploy the same configuration into both stages (dev and prod) since you will completely change the backend configuration in the next step, to make it more dynamic and flexible.

15. Click Actions > Deploy API and select the dev Deployment stage before clicking Deploy.

Always remember that you can test your API integration in the AWS Console before deploying it (return to Method Execution and click TEST). This way you will also be shown the corresponding API Gateway logs for debugging purposes.

Summary

In this Lab Step, you configured the API backend integration to use the Lambda function you created. You deployed the updated API to both the dev and prod stages.