Exposing AWS Lambda functions with the API Gateway
Amazon API Gateway is an AWS service that enables developers to create, publish, maintain, monitor, and secure APIs at any scale. You can create APIs that access AWS or other web services, as well as data stored in the AWS Cloud. Together with AWS Lambda, API Gateway forms the app-facing part of the AWS serverless infrastructure.
In this article, we will start with the most basic AWS Lambda function, fronted by an API Gateway endpoint, and incrementally step through some of the most used and key aspects of the integrating these two together. If you still have not seen the Sigma IDE for Serverless computing, just open up https://sigma.slappforge.com and register for a new account for free!
The basic Lambda function
Lets start with the empty Lambda function given by default by the SLAppForge Sigma IDE for Serverless computing, and add two console log lines to print the received event, and the context at the Lambda function.
We will then just drag an API Gateway trigger from the palette on the left, to line #2, to set up all of the magic that creates the API Gateway resource and connects it to the Lambda function.
If you would want to trigger your Lambda function with a different AWS resource, simply drag that into your trigger line (#2 above). For those getting started, we now define the API Gateway endpoint by providing a name and the resource path, and also configuring the allowed HTTP methods and advanced parameters such as Lambda proxy integration and CORS — more about these later!
Next click the deploy button, and it will take you through a code commit step, followed by the actual build process and deployment — and all the complexities of AWS CloudFormation is being done for you behind the scenes, while keeping you updated of each step and detail. Once the deployment completes, you will be presented with the URL of your deployed endpoint, which we will invoke next.
Invoking the Lambda function via the API Gateway
We will be using curl to invoke our Lambda function, and we will first send a JSON payload with a POST request as follows
As you can see, we receive a bunch of HTTP headers, and the return string “Successfully executed” from the Lambda function, as the response body.
The Sigma IDE automatically opens up the live SigmaTrail, and shows you the output of the logs, which will show you the Event and Context objects passed to the Lambda function.
You can notice that the raw input you provided to the HTTP request has been made the ‘event’, and that the ‘context’ contains additional information such as the memory limit and the unique request ID etc.
Effect of Lambda Proxy Integration
In some scenarios, your Lambda function might want to receive and set the HTTP level details from the API Gateway, and this is when you would want to enable Lambda proxy integration for your deployment.
Lets click on the Lambda trigger icon again (line #2), which will open up the API Gateway trigger configuration. Next we will go to the advanced options, and enable ‘Lambda proxy integration’. Note that the configuration will now inform you that the Lambda function must now return a response of the following form.
Next redeploy the project (not Quick Deploy — since we are changing the core configuration of the project, and not just the code) and resend the request and check the output.
Note that the ‘event’ now includes the resource, its path, method, headers, query string parameters, source IP, etc and the payload body.
At the same time, your curl call would have received a HTTP 502 error, since we did not modify our Lambda function to comply with the response format required for Lambda proxy integration. Next lets update the Lambda function as follows, to comply with the minimum requirements — and to provide the HTTP response code and body. We will simply copy the source body as the response body in this example.
Your output for the curl invocation will now be as follows. Note the request body being echoed back.
Request Path, Query Parameters and Headers
From within your Lambda function, you can read the following fields of the event object. Lets assume you invoked the following curl command
curl -sD — -d ‘{ “name”:”John”, “age”:31, “city”:”New York” }’ -H ‘Content-Type: application/json’ -H ‘X-TOKEN: 3456’ ‘https://1k9pzdx58d.execute-api.us-east-1.amazonaws.com/dev/apig-example?query1=33&query2=44'
event.path = ‘/apig-example’
event.queryStringParameters.query1 = 33
event.queryStringParameters.query2 = 44
event.headers[‘X-TOKEN’] = 3456
Setting HTTP response headers and code
Simply customize the response HTTP by setting up the response object required for Lambda proxy integration. You can setup a custom HTTP status code, headers and of-course a response body.
Enabling CORS
When your API’s resources receive requests from a domain other than the API’s own domain, you must enable cross-origin resource sharing (CORS) for selected methods on the resource. This amounts to having your API respond to the OPTIONS pre-flight request with at least the following CORS-required
response headers:
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin
Simply enabling CORS from the API Gateway trigger configuration does what’s required. However, when Lambda proxy integration is also enabled, you would need to set at least the ‘Access-Control-Allow-Origin’ on the response manually. See this thread on StackOverflow for reference.
