Lab Steps

lock
Logging in to the Amazon Web Services Console
lock
Understanding RESTful APIs
lock
Defining New API Gateway Resources
lock
Creating an AWS Lambda Function Backend
lock
Versioning and Aliasing the Lambda Function
lock
Configuring the API Gateway Backend
lock
Following Best Practices for Versions, Aliases, and Stages
lock
Creating API Keys and Usage Plans
lock
Enabling CORS on API Gateway Resources
lock
Enabling API Gateway Caching and Throttling
lock
Cleaning up API Resources and Lambda Functions
live-help Need help? Contact our support team

Here you can find the instructions for this specific Lab Step.

If you are ready for a real environment experience please start the Lab. Keep in mind that you'll need to start from the first step.

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:

alt

 

2. Click Integration Request and set the following values:

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

alt

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:

alt

 

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):

alt

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:

alt

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:

alt

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 FunctionItemsFunction:dev
  • Mapping Templates:
    • Request body passthroughWhen 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:

content-copyCopy code
{
"ID": $input.params("ID")
}

alt

 

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:

alt

 

13. Click the check mark 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.