Validate Your API Request At The API Gateway Using Serverless Framework

We often validate the inputs to the API after the request reaches our lambda, this is a common practice. Well, we have another way!

Let’s Get Straight To The Concepts

The API Gateway has a functionality that allows us to validate the request to our APIs before routing it to the specific lambda function. To achieve this, we need a simple setup of JSON schema validation template. The incoming request will be validated against this template and we need to add some properties to the specified functions in serverless.yml file.

If you don’t know how to set up a serverless project or create a lambda or an API, you can refer to the following blogs:

  1. A Complete Guide on Deploying AWS Lambda using Serverless Framework

  2. Introducing Full Control To Your APIs Using Serverless Framework

The Setup

I assume that the configuration for the Rest API that you created would look similar to this. I have created an API that will add an employee record to the database table.

serverless.yml

In order to provide the request validation, we have to add a request object to the HTTP event. This object will contain the validation schema for your API request validation.

configuration for request validation

I have added request.schemas.application/json property to the HTTP event object. The ${file(validation_schema.json)} is the way to import any external file in the serverless.yml file. Here validation_schema.json is the file name.

I have written a simple JSON schema model to help you understand these concepts:

The payload that arrives at the API Gateway must have a request model according to the JSON schema draft 4 only, other drafts are not supported currently. If you read the above model, it’s simple to understand. I have specified the JSON draft URL, the type of request that is object , the required fields, and the properties related to each field!

The best way to deal with null values is to specify a pattern, also it can be used for matching email strings, defining rules for names, etc.

Once deployed, Let’s try this out in Postman!

The request with the email as an empty string

As you can see, we have got a 400 Bad Request , you will get the same response if you specify null or don’t pass either email or designation fields because we have specified these as required.

Let’s give the correct values:

Success Request

And there it is! We got a 201 Created Response!

Nested Field Validation

You can also specify the properties for nested requested objects, which is one of the most common request formats.

Here I have added another property past_companies_and_experience which is an array of objects.

Let’s test our request for this format:

Testing requests with nested objects

As you can see, we have successfully added the data, one thing to note here is that we have not specified past_companies_and_experience in required fields and hence, we won’t get any error even if we don’t pass it.

But if we specify the past_companies_and_experience array, the values cannot be null, because we have specified a pattern.

Passing invalid values

The example that I have shown here is for the POST or PUT APIs, however, we can also specify the models for the GET API’s response! Configuration is the same as above.

One important thing to note is sometimes we might have similar requests for APIs, hence we can also reuse the models for multiple APIs instead of specifying the configuration for each and every function in serverless.yml file. The method to configure is you just need to shift the request object to the provider.apiGateway object with slight changes and reference it into functions by key.

Defining the JSON schema globally

Also, check this reference for more! You can find multiple ways of creating the JSON models according to your requests.

Conclusion

Alright, that’s it for this blog. I hope this would be useful. Thank you for spending your valuable time.

0
Subscribe to my newsletter

Read articles from CodeOps Technologies directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

CodeOps Technologies
CodeOps Technologies