Building Your First Serverless App - Part 2

This post continues on from part 1 in this series so make sure you check that one out if you haven't already.

In the first post of this series we finished off by testing our customers endpoint using curl. Today I'll show you how to test the same endpoint using Postman which, for the folks that haven't used it before, is a desktop app that makes API testing incredibly easy. I'll also help you track down your request url if you aren't sure where to locate it, and show you a handy feature in Postman.

Before we begin, if you don't already have it installed, head on over to the Postman website and get the app set up on your machine. Once it's installed, launch the app and and click the '+' tab along the top to bring up the screen where you'll need to make your request.

In order to make your first request, you'll need the request URL which was generated when you deployed your lambda at the end of the previous post.

Your request url will have a different domain to mine. If you didn't take note of it after you last deployed your lambda, there are a couple of ways you can access this.

The first option is to simply deploy your app again. However, if you haven't made any changes this is a little redundant. Alternatively, you can log into the AWS console.

From the search bar type in 'API gateway' (AWS's service where we can create and manage APIs) then click on the first result.

On the next screen, click on the name of your API:

Finally, in the left-hand panel click on 'Dashboard'.

You should see your request url in the blue bar near the top of the screen. Copy that and head back to Postman.

Now that you have your request URL, let's save it. You're going to need to access this multiple times and we don't want to have to log back into the AWS console each time or even copy and paste it from a past Postman request.

Along the top, click on the eye icon and then click 'Add' in the top right of the modal that appears.

The next modal is where we are going to save your request url as a variable so you can easily access it any time you want to test a request.

To start with, you'll need to come up with a name for your environment. This will allow you to group test API calls together easily. Next, Give enter a a suitable variable name for your request url and then past your url into the initial and current values. Finally click 'Add'.

Close the modal and then, in the drop-down in the upper right, select the environment name you just created so you can access your variable when we go to make our request.

Next, change the method from GET to POST in the dropdown and enter the name of the variable you just created in double curly brackets. Typing in your variable name this way is all you'll need to do to access your request url from now on.

There's only a few things left to do to test out our saveCustomer function. The first is to add your endpoint to the path of your request url:

Now it's time to add the body of our request to save our customer. As we haven't yet defined what properties our customer object has, we can enter anything we want for this test.

In the middle navbar click on 'Body', select 'raw' from the radio buttons, create an object with whatever random properties you'd like, and hit the blue send button.

And voila! A 200 response with the message we added to our function in the first post.

Obviously, it doesn't do much good to have a lambda function that doesn't define what properties can be passed in so we'll update that in the next post. I'll also show you where you can access logs which you can use for monitoring and debugging.

One final thing before I wrap up: save your request. You can do this by hitting cmd + s (or ctrl + s for Windows users) or by clicking 'Save'.

In the modal, give your request a name, scroll down and click '+Create Collection' and give your collection a name (the name of your app is usually a good way to go), and click the save button.

Under the 'Collections' tab to the left you should now see a folder with the name of the collection you just selected. When we make future requests to different endpoints, we can save each request here in this collection making it easier for us to test endpoints over and over again without having to redo any of the setup.