Setting up simple Amazon API Gateway in minutes : (Part 2 of 2)

This is a continuation of the previous part ( link to the post). To know more about the AWS API gateway refer to :https://aws.amazon.com/api-gateway/. As, we finished the database connectivity in lambda function in the previous part, let’s jump right into API gateway to build and connect in this post (Setting up simple Amazon API Gateway in minutes):

Amazon API Gateway

To start with login to your AWS account and under services search for API gateway. It’s under Networking & content delivery section.

There is another way you can start creating the API gateway for this, which is from the lambda function. Let’s use this method for this post. This will be more efficient in this case and will talk about some of the adjustment we might need to make it work. So let’s go to the lambda function which we want to expose as a REST API. In the designer click on Add trigger button.

Fill up the options as below and keep default as much as you can for this post. As you might see this will create a REST API with API Key authentication for you. The details of the API key will be talked about in a little while. But once you have this ready click add and you should see the API gateway for you.

Click on the API gateway name to open the API details as below:

Click on the Actions button to create a GET method. For this post we will create a GET method but process is same for other types of methods as well.

This above steps will create a GET method that can be called from external systems to gain some data returned by the lambda function.

Along with this it will create few more things:

1 An API Key to be used by the client / caller application

2. An Usage Plan and the API key will be linked to this Usage plan

What are usage plans and API keys?

A usage plan specifies who can access one or more deployed API stages and methods—and also how much and how fast they can access them. The plan uses API keys to identify API clients and meters access to the associated API stages for each key. It also lets you configure throttling limits and quota limits that are enforced on individual client API keys.

API keys are alphanumeric string values that you distribute to application developer customers to grant access to your API. You can use API keys together with usage plans or Lambda authorizers to control access to your APIs. API Gateway can generate API keys on your behalf, or you can import them from a CSV file. You can generate an API key in API Gateway, or import it into API Gateway from an external source. For more information, see Set up API keys using the API Gateway console.

An API key has a name and a value. (The terms “API key” and “API key value” are often used interchangeably.) The value is an alphanumeric string between 30 and 128 characters, for example, apikey1234abcdefghij0123456789. Important

API key values must be unique. If you try to create two API keys with different names and the same value, API Gateway considers them to be the same API key.

An API key can be associated with more than one usage plan. A usage plan can be associated with more than one stage. However, a given API key can only be associated with one usage plan for each stage of your API.

A throttling limit is a request rate limit that is applied to each API key that you add to the usage plan. You can also set a default method-level throttling limit for an API or set throttling limits for individual API methods.

A quota limit is the maximum number of requests with a given API key that can be submitted within a specified time interval. You can configure individual API methods to require API key authorization based on usage plan configuration. You can also use the get-usage CLI command or the usage:get REST API method to determine the usage for an API customer. Note

NOTE : Throttling and quota limits apply to requests for individual API keys that are aggregated across all API stages within a usage plan.

Configure the API and query string

After you we have created the method the default values will be something like below. Make changes so that the screen will look like the screenshot which is After (After changes). By doing this change we are lining the API key , so that the request will be validated using the API key we created in previous steps. Also we have made changes so that the request header , body and query parameters will be validated before making the API call.

Notice the query string parameter we created in the above screen shot. As we marked that parameter as required the validator will need this to be filled in. If this value is missing in the API Call the request will fail. The below screen shot shows that, we need to have the query parameter populated while firing the call.

Once we filled the query parameter as below screenshot the API call will succeed as the below screenshot.

Testing and deploying the API

Run a few more test as we did in the previous step by running different queries. If you find any of the below issues make sure you followed the above configurations correctly.

Lambda execution failed with status 200 due to customer function error: Cannot read property 'query' of null. 

If you look at the log section in details you will see an error something like :

{
  "message": "Internal server error"
}

Response Headers

{"x-amzn-ErrorType":"InternalServerErrorException"}

Now if all looks good after the testing go go resources, select the “GET” method . Go to actions and click on “Deploy API”.

Fill-up the deploy API form as below and click “Deploy”

This will give you an end point so that you can make API calls.

Go ahead and use any REST API client e.g Post Man and hit this endpoint using the API Key you have generated in previous steps above. Note the below points:

1. The method will be set to GET in the client
2. The end point will be appended with the service name : add /TEST (as per this post) to the end of the URL. See below screenshot.
3. Header must contain : “x-api-key” : YOUR API KEY FROM ABOVE STEPS
4. Parameter should be added to the URL.

Conclusion

This is the end of the 2 post series “Setting up simple Amazon API Gateway in minutes“. This is a very basic start and this can be made robust by adding more authentication options using Lambda and other services. There are more configuration which can be made to make it more production ready. Hope this post will get you started. Post comments if having trouble and will try to solve if there are any queries. Let me know if you see any mistakes in this post as well. Any feedback is always welcome 🙂 Keep reading and keep sharing ….