Using Postman to Test the Deployment

In the previous lab we ran the scripts for the first time to deploy the SAM version of the sample code to AWS. In this lab we’ll step through setting up and using Postman to run API tests that will verify that deployment.

Setting Global Variables in Postman

There are three APIs in the deployed solution, and there are three corresponding test collections that you’ll have previously imported into a workspace in Postman. To keep things simple, in this lab we’re going to focus on setting up Postman to test the Admin API.

Step 1: Get the generated ID for the Admin API

The first step in setting up Postman is getting the value for the generated ID for the Admin API. If you were able to keep VS Code open from the previous lab, then you can get the Admin API ID output value from the terminal. In the screenshot below, at the bottom, you can see that this ID has a value of “523hstucfc”:

Alternatively, these outputs can be found in the console, as we saw in the previous lab, on the CloudFormation Stacks page. These API IDs are also displayed on the main API Gateway page. Wherever you go to find get this ID value, copy it somewhere close to hand, because you’ll need it shortly.

Step 2: Get the generated API key for the Admin API

The second value that you need is the generated API key that’s used to secure the Admin API. This property can’t be directly referenced as a stack output, which is why you don’t see it displayed in the terminal above. There are command-line techniques you can use to get this value, but we won’t cover these until a subsequent lab.

For now, you can get this value from the console. Start by navigating to the API Gateway service and selecting the Admin API. You’ll see the “Resources” option initially selected for the API. Select the “API Keys” menu option on the lower left, and then select the API key displayed in the next panel to the immediate right. At this point, you should see the API keys properties as shown below:

The value of the API key is hidden by default. Click the “Show” link, and the value will be displayed, as shown in the example below:

As with the Admin API ID, copy this generated API key and put it somewhere close to hand.

Step 3: Set the Global Variables in Postman

Now let’s take these two values we’ve obtained and set the corresponding global variables in Postman. Start by launching Postman and selecting the workspace into which you’ve imported the three test collections and the global variables. Then select the “Admin_API” collection. You should see something like this (bear in mind that the UX for Postman is constantly changing):

At the very top-right of the screen above, there’s a square icon with an eye, which you should click to open a dialog box that shows the available environments and global variables:

Next, click the “Edit” button on the right of the “Globals” panel. You should now see the editable “Globals” tab for the global variables, like this:

On this page, copy and paste the Admin API ID value into the row for the adminApi variable on both the “Initial value” and “Current value” columns. Then do the same thing for the API key value, copying and pasting this value on the apiKey row.

The other variable values can be left as is, with the possible exception of the region variable. If you’re working in a different region than the one shown above, you’ll need to update the two values for this variable as well. Once these variables have been updated, you can click the “Save” button at the top right, and close the “Globals” tab.

Running API Tests in Postman

Step 4: Run the Create Dealer test in Postman

Now, let’s run the first test in the Admin_API collection. Expand the “Dealers” folder in the collection and select the “Create Dealer” test. You should see the tab for this test, as shown below:

To run the test, just click the blue “Send” button at the top right. Once processed, the response should display in the panel at the bottom. A successful response won’t display any JSON, because the create dealer endpoint doesn’t return a response body. Instead, you’ll see a “201 Created” status at the top right of the bottom panel, in green:

As per standard REST practice, this endpoint also returns a “Location” header value. We won’t use this value here, but it’s good to know that this header provides a URL path on which the newly created resource can be queried:

Step 5: Run the Get Dealers test in Postman

Next, run the Get Dealers test to confirm that the previous test successfully wrote data to the Dealer DynamoDB table. Here’s an example of the response you should see after sending a request for this test:

The JSON response body for this test should include an array of Dealer items. In this case, there’s only the one dealer which we just created:

Note that if you run this test again, right away, the response time will be much faster. In these examples, the first response took 1715 milli-seconds, while the second took only 116. This is not a result of data caching. It’s a result of the Lambda cold start phenomenon, which is something that we’ll cover in detail, later in this course.

Step 6: Run the full Admin API test collection in Postman

If the first two tests have succeeded, then we’ve confirmed that our Postman configuration is correct. So let’s finish up this lab by running the full Admin_API test collection. To start, close any currently open tabs in Postman, select the “Admin_API” collection, and on the tab that opens, click the “Run” button at the top right. You should now see a new “Runner” tab, something like this:

All the default settings in the panel on the right can be left as they are. Click on the orange “Run Admin_API” button on this panel. The tests will run in sequence, and once completed, the results should look like the screenshot shown below, with 25 tests passed and zero failed: