Testing API Gateway Endpoints in the Console

For the labs in this section we’re going to work with the OpenAPI version of the sample code. We’re starting in this first lab by deploying this version to AWS, and then showing how you can test API Gateway endpoint integrations directly from the console. In the labs that follow, we’ll test the request validation that the OpenAPI version supports as well as the Cognito Authorizer and the Customer API.

Deploying the OpenAPI Version

Step 1: Check that the previous SAM deployment has been deleted in the console

At the end of the labs in the previous section, we stepped through deleting the SAM deployment. Go now to the CloudFormation stacks page in the console and confirm that there’s an empty page, as shown below. If the SAM deployment did not get deleted, then jump back and go through the last step of the final lab in the CloudWatch section before moving on.

Step 2: Set the config.zsh script variables in VS Code

Next, copy values for the “workspacePath” and “bucket” variables that you set in the configuration script in the SAM version and paste them into the same place for the OpenAPI version of this file.

Step 3: Run the deployment scripts in the terminal

From the terminal in VS Code, make sure you’ve changed to the “/deployment/openapi/scripts/zsh” folder. Then, as you’ve done before, run the three deployment scripts in sequence: clean.zsh, build.zsh and deploy.zsh. Once the last script has finished executing, go to the AWS console and navigate to the CloudFormation stacks page. Just like the SAM version, the deployed stacks should look like this:

While still in the console, it’s worth taking a look at the Admin API just to confirm that you’ve deployed the correct version. To do this, navigate to the API Gateway service, select the “ConnectedCar_Admin_API_Dev” API, and then click on the “Models” menu option on the left. You should see the list of models, as shown below (with the “Address” model selected):

If you don’t see these models, then mostly likely you’ve deployed the SAM version of the sample code. You’ll need to delete the stack and start again.

Testing Endpoint Integrations in the Console

Up to now you’ve been testing the APIs over the wire with Postman. However, you can also test endpoint integrations directly from the console, which we’ll demonstrate now.

Step 4: Test the Create Dealer endpoint integration in the console

Let’s start with a familiar endpoint. First, you’ll need a snippet of JSON for the request body, which you can get from the tests in Postman. Navigate to the “Create Dealer” test in Postman, and copy the request body, as highlighted below:

Back in the AWS console, select the “Resource” option on the left, then click on the “POST” method for the “/admin/dealers” resource path. You should see this page, as shown below:

Next, click on the “TEST” link, at the top of the narrow box on the left side of the right-hand panel. This link should take you to this “Method Test” page:

Now, scroll down until you see the text area for the request body and paste the JSON that you just copied from Postman. You should also change the name field to some different value, like you see below:

Then, click the blue “Test” button at the bottom of the page, wait for the page response, and scroll back to the top. You should now see information about the HTTP response for the test, plus an interesting set of log entries for the Lambda invocation:

If you look at the “Response Headers” panel on the right, you’ll see that the first header contains the REST-standard resource path for the newly created entity. The second header contains information that helps the X-Ray service trace the call stack. The logs are interesting to look at as well because they show the process of API Gateway transforming to and from the Lambda invocation format. Note that if the Lambda throws an uncaught exception during execution, that exception will be logged here as well, which can be useful when diagnosing a problem.

Step 5: Test the Get Dealers endpoint integration in the console

Let’s now perform a similar test, but for the “Get Dealers” endpoint integration. To do this, click on the GET method for the same resource path, and once more, click on the “TEST” link. You should see a “Method Test” page similar to what was displayed above, but this time without a request body entry field. In the “Query Strings” field, enter “stateCode=OR”, as shown below:

Once again, scroll down and click the blue “Test” button. The HTTP response details should come back looking something like this, with the JSON for the dealer displayed in the panel for the “Response Body”:

Step 6: Test the GetDealer endpoint integration in the console

To round out this series of tests, try the GetDealer endpoint integration. This endpoint has a path parameter for the dealerId, so copy the GUID for this parameter from the response for the previous test. Then, select the GET method for the “/admin/dealer/{dealerId}” resource path and parameter combination, as shown below:

As before, click on the “TEST” link, and paste the dealerId value into the “Path” field, as shown below:

When you scroll down and click the blue “Test” button, you should get HTTP response details that are similar to those for the previous test. The difference is that the response body has a single Dealer JSON item rather than a dealer item within a JSON array:

Bypassing Security & Request Validation

An important thing to note about testing integrations from the console like this is that you’re bypassing both the security authorization and request validation for the selected endpoint. Normally, you need to include an API key in the headers for requests sent to the Admin API, for example. But you don’t need to include those from here. Likewise, this OpenAPI version of the sample code adds request validation based on the data schemas defined in the schemas.openapi.yaml file, but this validation is bypassed when testing from here.

Although you can’t test the security or request validation from here, this testing mechanism displays the logs and response information all in one place. This makes it a useful way to debug both the functionality of the target Lambda and the service roles associated with its invocation and execution.