Restful webhook using Lambda + API Gateway — PART 2
Part 1 of this series dealt with the steps that one must follow to expose a simple GET method on API Gateway that mapped to a handler function in Lambda.
Part 2 will dwell on the steps(though similar to the GET) that will build up to creating and deploying a custom made handler and API URL for the POST request.
You must be wondering as to why does POST deserve its own separate space when there is minimal change in the integration. Well, I did have this impression while starting the following exercise but soon realized that the issues and bugs I encountered must be documented.
Also! Remember we are building up to this:
The piece of set up that we will go through shortly is crucial for this entire orchestration to work.
So here goes!
Lets have a look as to what we will try to achieve here:
Lambda:
If you have followed Part 1 and wish to reuse the Lambda Code then we can then proceed to the actual code; skipping the part of zipping up the code.
The Code we will be looking at is:
Notice a few things here:
- We are specifying /serviceGithubhooks as the Resource which will attend to POST requests.
- Line 9 and 10 looks at extracting the author name for the Commit that was recently made; from the JSON object that is received from GitHub.
- Line 13 to 26 then looks at building a response object with the author name and a predefined message. This message is to understand that the response indeed was received from our Lambda Function.
Place this code in your existing lambda_function.py code; preferably after the get_hello() method that we created in Part 1.
Since we haven’t added any additional dependencies, it is fine to re add the lambda_function.py file to the existing deployment zip.
To Avoid confusion we will create a new Lambda Function named serviceGithubhooks (similar to the Resource name) and upload our zipped code.
Modifying Runtime Settings:
The Handler settings gives Lambda an idea as to which method it needs to execute once it is invoked. In our case lambda_function.app is suitable as this refers to our Flask application name.
Execution Role:
Since API Gateway will be invoking the Lambda; we will need to provide an inline invoke policy to API Gateway for Lambda. Essentially this inline policy allows API Gateway to this Lambda function.
Confused! This is the tricky part where in we will attaching this inline policy to the Lambda function.
Looking at the permissions tab; each lambda gets a Basic Execution Role for it to write logs to AWS Cloud Watch.
We will attach our inline policy to this Role.
Go ahead and edit this Role and select attach inline policy which will allow you to specify the JSON object.
Note: The statement section of this policy is the important part. It is here that we are allowing (Effect Section) any requests made to the regex pattern (Resource Section) to invoke this Lambda and Invalidate any cache that would exist (Action Section).
Go ahead and save this policy with a name of your liking and we will get the following resultant window:
Apart from the Basic Execution Role our Lambda now has the invoke inline Policy attached to it.
API Gateway Trigger:
Another easy way to create a method for our post request is to add a trigger from the Lambda Function’s UI. (if you wish to reuse an existing API).
Go ahead and add a trigger and specify the API name and the stage in which you want to create this resource.
Viola! Lambda thus creates a Resource for you in the API of your choice on API Gateway.
API Gateway
Since we created a trigger from Lambda we will simply navigate to the existing API to find our Resource (that Lambda created for us).
Select the POST method and specify the Lambda that will service the requests intended for the resource serviceGithubhooks.
Once done you should now see the above mapping summary.
Bug in the system:
There seems to be a certain bug (while this article is being authored) in the API Gateway UI when it comes to POST requests. Due to this bug you will often see errors of this nature from Postman(even after your API is deployed):
which suggests that there is something wrong with the Resource — to — Lambda Mapping.
As per this stack overflow link the following steps will help overcome this bug:
- Open the POST method of the Resource
- In the mapping window select Integration Request which will ask you to reaffirm the Target Lambda function.
Though this step was performed earlier; edit the Lambda Function section and re-enter the Lambda function Name and click on the tick mark to save the settings.
Lets re-deploy the Test stage and extract the URL.
Armed with the URL and a dummy JSON object (to be used in the requests Body) we head over to postman.
Note: The JSON object we used was extracted from GitHub’s Webhook window which will provide the Body and header information. This is available while you try to set up a Webhook on GitHub.
Viola!!! After a lot of fidgeting we have finally established an integration to handle POST requests.
In a nut shell:
- We sent a POST request to the /serviceGithubhooks Resource of our API.
- API Gateway then rerouted this request (made from Postman) to the specific Lambda function(as initialized while creating the Method for resource /serviceGithubhooks).
- The Lambda Function then mapped this request to the python function foo() (using the wrapper @app.route() method) which responded with the JSON object. foo() extracts the author name from the commit array that is received from GitHub and sends it back.
- This Resultant object then travels back to our Postman Client.
Congratulations for reaching so far!
I hope this tutorial was easy to follow as we had to unpack a lot information in such a short time and also understand API Gateway’s idiosyncrasies.
Do feel free to leave some feed back on any aspect I might have invariable excluded.
