Simple Cloud-based API Mocking with AWS API Gateway
There are a few situations in software development that call for “mocking” your back-end API in order to fake certain data scenarios. I’ll show you how to set up fast, cloud-based API mocking in a tool most dev teams are already using: AWS.
What is Mocking?
API Mocking is the process of delivering fake responses that are not composed or delivered by the client’s actual middleware. Instead, “mocked” responses are prepared and sent back from some other service or application. This outside service generally doesn’t have any logic or authentication; it just serves static responses to all requests in order to simulate the real thing. Mocked responses are usually remotely configurable or editable so that lots of different use-cases can be exercised quickly without the overhead of creating test accounts or arranging data in databases to cause the actual backend to response in a particular way.
Why do we need Mocked APIs?
Mocking is most-generally used to facilitate both manual and automated front-end testing. When you’re testing the front-end only, you don’t need to exercise the actual backend, you only want to verify that the front-end behaves the way you expect given some input-data — the mocked response.
API Mocks can also facilitate development of front-ends concurrent with (or even in advance of) backend development. If we know what data we eventually expect an API to return, we can mock it and build a front-end to display it before the API is functional.
Setup a Mock Service in AWS API Gateway
To set up mocks in AWS, first — in your AWS account — go to API Gateway, and create a new API:
Then scroll down to REST API, and click “Build”
And finally, choose REST → New API, and name it. Then click “Create API.”
Create new Resource and Method
Now that we have an API, we need to add a Resource, or route, and Method, such as GET or POST. To do this, select your new API, then click the “Actions” menu and select “Create Resource”
Then name it, edit the path however you want, and create. Usually, the path should match some actual API path that you’re mocking.
Next, create a method. We’ll start with a GET. Select your new resource, and then choose “Create Method” from the Actions menu
Then, from the drop down, choose GET
Then configure the Integration Type as a mock:
Set up a Mock Response
Now that we have a route and method, we need to configure a response. After all, that’s why we’re here in the first place. To do this, select your new Method, then click “Integration Response,” on the bottom right.
Now expand the 200 response, then expand “Mapping Templates” and add a template. Set the content-type to “application/json” and enter your mock response in the edit-text:
Since you’re probably mocking a real API, this is where a fake version of its response would go. AWS also offers a template feature, so that you can create data models for your APIs and use those to generate a mock.
There are also tons of other features and a simple programming language you can use to do things like accept query parameters, and return different data based on the values.
Deploy your API
Almost there. Now that you’ve configured an API mock with a static response, you have to deploy it so that you can use it. To do this, go back to your API, hit the Action menu and choose “Deploy API”
The first time you do this, you’ll need to create a new deployment stage. Just select [New Stage], name it, and hit deploy:
AWS will give you the URL of your API, and you can start using it. And now you’re all done. If you want to be. But you also might want to know how to…
Mock Error States
No mocking solution would be complete without the ability to mock errors and edge cases. In API Gateway, there are two ways to do this.
The Quick Way
The easiest way to mock an error is to modify the mocked response you set up earlier. To do, go back to the Integration Response, open up your mock and an the top, enter
#set($context.responseOverride.status = 500)
Re-Deploy your API, and now you’ll get a 500 by default.
The Best Way
Notice in the previous solution that the body of the API is the same. We only changed the status code. If you have an error body that you want to provide, you’d have to switch the entire body of the integration response every time you want to switch between an error and a success.
A better way is to configure an error scenario that you can switch to whenever you want without replacing the success response. This way you can keep both and decide which to send.
To set up a switchable error response, head over to the Method Response section of your GET:
Then select “Add Response”
And create a response for your error. We’ll use 500. After you create it, expand it and add an empty response body:
Next, go back to “Integration Response”, and click “Add integration response”. Select 500 from the list.
We’ll configure our integration to return 500 for any 5xx error, using the regex 5\d{2}. Don’t forget to Save it.
Finally, if you want, add your error body, the same way you did for the success body, in “Mapping Templates”:
Switch to your Error Response
Now we’ve configured the error, but our api still returns success. To change this go back to your method, and select Integration Request:
Expand the Mapping Templates and select the application/json template. Modify it with whatever error code you just configured (ours is 500):
Save everything, Deploy your API, and party. Your error and response are saved now, so any time you want to switch between it and your success response, just come back to this section and update the status code in the mapping.
Ok, now you’re done.
In AWS API Gateway, there’s a decent amount of setup to accomplish a solid mock, but it might be worth it, since you’re probably already using AWS.
The API Gateway will also let you import a swagger doc to accelerate things if you want. All in all, as mocking solutions go, it’s relatively painless, fast to setup and there are a myriad of options for managing access.