So, we understand why Mocking is a thing, but how exactly do we do it? With API Fortress, mocking an API is a straightforward process. This article will go into how it’s accomplished and discuss a few use cases.
The first thing that a user needs to do is login to API Fortress. Next, they need to click the “Tools” icon in the upper right-hand corner.
This will bring the user to the mocking interface itself. Once here, we can add a new mock endpoint. To do so, click the “+Add Endpoint” button or the green “New Endpoint” button.
The next step is to use the New Endpoint Modal (which is a fancy way of saying ‘the window that just popped up’) to define our new endpoint!
The Domain field will be just that – we’re entering the name of the domain that we want to refer to. This will come before the hosted server we choose. In the image example below, the domain will be “m206-demonstration.staging.apifortress.com.” The customizable part is “demonstration.” The rest is defined by API Fortress and the server you’re hosting the mock endpoint on.
The Path field will be everything that comes after the TLD (Top Level Domain; .com, .net, .co.uk, etc.) In the example below, the Path is defined as “/api/demo”. Once we hit Continue, we’ll be defining the whole endpoint as “http://m206-demonstration.staging.apifortress.com/api/demo”.
The whole mock endpoint will be visible in the blue field of the modal, and will change as you update it. Let’s click continue and move on to the next step.
If we click on the domain we just created (demonstration), a new pane will open showing us our /api/demo endpoint. We’re very close to having a functional mock API. Just a few more steps and we’re in business. If we click on the path itself, we’re presented with the following view. Click the highlighted button to Add a Response Case.
When we click Add Response Case, we’ll see this:
There’s a lot going on in this view, so let’s go through it piece by piece.
At the top of the page, we see our Domain, Path, and Full URL. Clicking the URL will copy it to the clipboard automatically. Let’s remember that for later!
In the red-bordered box, we can define the actual response to our endpoint.
- Method: This dropdown allows you to select the REST verb of your choice which this route will respond to. The options are GET, POST, PUT, PATCH, DELETE or “*”. “*” is the wildcard operator. It will respond to a request with ANY of the listed verbs.
- Expression: This field allows you to define expected values for a number of different parts of the request. The checkable values are as follows:
An example value for this field would be “request.headers[‘accept’]==’application/json’.” If the ‘accept’ header was not ‘application/json’, a request would be deemed invalid in this case.
- Content-Type: This defines the content-type of the response body.
- Status Code: This defines the status code that will accompany the response to properly formatted requests to this endpoint response case.
- Description: This is an internal description to help you remember the functionality of this endpoint.
- Headers: Define any response headers that should accompany the response.
- Response Payload: This field is where you define the response payload itself.
Once all of these fields are defined, we can click “Save Changes” in the upper-right corner. At this point, our mock API route is fully defined. We can access this mock route from any platform that can access the network on which it’s hosted.
Here, we can see the mock endpoint being accessed from API Fortress’ own HTTP Client. Similarly, the endpoint can be accessed by any web browser. So, now we understand the how, but what about the why? Why should we mock an API endpoint? There are a lot of answers to this question, but they primarily break down into two categories. Those categories are:
It doesn’t exist (yet).
I can’t get to it.
The “It doesn’t exist” argument is the easier of the two to explain, mostly because the explantation is in the title. Oftentimes, development teams depend on information from other teams to develop new features. Perhaps the front-end team needs data from a not-yet-operational products microservice to render a list of products as a result of a search. Instead of waiting for database schema to be defined, the database to be populated and the server API routes to be written, they can simply create a mock endpoint that returns identically structured data and leverage that until the products service is live.
The “I can’t get to it” line is a little more difficult to address directly, because it encompasses more varied issues that “it doesn’t exist.” In some cases, development environments are restricted heavily with regards to what they can access. Let’s take that first example again, but this time, host the product service outside of the development environment. The product service is fully developed, but it’s on the wrong side of the firewall. The development team could contact DevOps and Security to request they whitelist the IP of the service. Instead of waiting for the gears of bureaucracy to turn in their favor, the team could create a mock endpoint inside of the firewall that they could access at will. The same sort of logic applies to a case in which each individual call to an external endpoint costs money. Instead of paying for each individual call during development, a mock endpoint could simulate the return.
Mocking is an important part of developing an API environment. With API Fortress, mocking is easier than ever. There’s no need to install new software. Every on-premises instance of API Fortress comes equipped with it out of the box. There’s no extra setup of any kind. API Fortress Mocking just works. Type in your domain, your endpoint and your response, and you can access the endpoint from anywhere that has network access. API Fortress makes testing easier than ever and the new mocking service is no exception.
API Fortress was specifically built for today’s agile architectures. A collaborative platform that bridges the gap between development, QA and DevOps. By collaborating using the simple GUI, teams can work together to create a series of powerful API test in one place. Then those tests can be executed at every stage of the lifecycle, in particular as part of the CI/CD process. Using our webhooks or Jenkins plugin, you can automatically execute tests and get notified of issues before the code is published live. The platform works in the cloud or on-premises, giving you the flexibility to run test from any environment while still satisfying security protocols. Catch errors before your customers find them and release code with confidence.