Using Mock Servers throughout the API Lifecycle
Throughout every stage of the development process, there are unexpected bumps and setbacks. These often delay or completely halt progress. As we integrate with more and more APIs, we inevitably spend more time than we‘d like debugging (individuals spend 16% of their time debugging APIs, compared to 10% in their ideal state). Whether you rely on external pieces of technology or just have multiple teams attempting to work concurrently, there are plenty of ways to get jammed up.
Whatever the case may be, it’s infuriating when you’re working with an API, internal or external, and development is interrupted. Fret no more—mock servers have you covered for all stages of the development lifecycle.
Related: What is the API lifecycle?
What exactly is a mock server?
Let’s back up a second to answer the above question. What exactly is a mock server? In the Postman API Platform, a mock server is a tool that allows you to make API requests and simulate the corresponding responses. When you send a request to a mock server, Postman will match the request configuration to the examples that were saved for the request and respond with the data that was added as an example.
This allows you to see what an API would potentially deliver in a production instance by mocking the request and example responses. Mock servers enable rapid development of API infrastructure without having to write code. This shortens the feedback loop and allows developers to iterate more quickly.
Postman makes it easy to create a mock server in several ways. In this blog post, we’ll cover some of the reasons why you may want to use mock servers, and then show you how you can add them to your workflow.
Using mock servers for collaboration
Development typically doesn’t happen by a single person or even a single team. Even small-scale projects can have frontend developers, backend developers, QA engineers, etc. To work as quickly as possible, different teams often work on different parts of the project at the same time.
Mock servers help keep this process as efficient as possible. They are versatile in that they can be used in many different stages of the API development lifecycle—for both API producers and consumers. Let’s consider an example where the frontend team wants to start integrating with data coming back from the backend/server. If the API endpoints are not fully configured and working, frontend engineering may not be accurate or even possible.
This is a basic example of where mock servers can be used in the earliest design part of the process. Instead of waiting for the endpoints to be built and deployed, you can use Postman to spin up a mock server from an API specification that will simulate server responses to be used on the frontend. The UI developer can get started right away by querying the mock server and working against the expected responses. When the actual API is production-ready, swap out the URL that accesses the mock API responses with the URL for the real API (you may also need to add any necessary authorization at this point.) The video below walks through how to set up and call a mock server:
Test efficiently by mocking external dependencies
APIs and projects don’t live in a vacuum. Backend development constantly integrates with other services. Unfortunately, calls to external servers are completely out of your control. They can produce unreliable, unexpected results. Servers go down and return 503 Service Unavailable errors for example. As referenced earlier, 16% of overall time working with APIs is spent debugging. If your project relies on a suite of external APIs, there’s a chance that at some point you’ll try to access an API that is experiencing failure and you’ll need to figure out how to continue. These instances don’t need to be a total blocker.
It’s common to have a call to an external server or API as a crucial component of your workflow. To avoid relying on external services during development, this is another scenario where we can use mock servers. Mock servers simulate the experience of hitting an external server and returning an expected response.
In this scenario, mock servers aid in the local testing and development phase of the development lifecycle. Let’s explore a theoretical example:
Say you have an e-commerce application with an ordering flow (pictured below). Your API is coupled with a shipping service that needs to stay in sync. Whatever is added to the cart in the e-commerce app needs to similarly be added to the cart for the shipping service. This allows the shipping service to keep track of what needs to be shipped. Essentially, every time a request is made to your own API, there will be a request to the shipping service API as well.
If you’re testing out your integration, you can use Postman to test each API directly. By isolating individual APIs in your workflow, you can determine if there are any issues with specific APIs. If the shipping API returns a 503 Service Unavailable error, this could halt further development or testing. By configuring a mock server for the external shipping API, you would still be able to continue working based on expected results from the shipping API despite it being down. This is a repeatable process for all your dependencies that are APIs.
Below is the same workflow but the Shipping API has been swapped out for a mock server simulating the Shipping API requests and responses. Now, as long as the internal APIs are working as expected—even if the Shipping API fails—testing is not affected by the failing API.
Talk data to me
Data is one of the most important pieces of the API ecosystem. Regardless of the HTTP verb or protocol used, sharing data between applications and systems is at the heart of all things APIs.
Data can contain sensitive personal user information, so you may not want to test with real-user data. But it can get boring and not realistic if all your placeholder data is “John Doe” who lives at “123 Main Street.” Whether you’re interested in protecting private data or simulating an actual production-like workflow, mocks help manage both everyday testing and tricky use cases alike.
Creating dynamic data for your mock servers within Postman is a valuable option. Postman comes equipped with several external libraries available, including Faker.js—a dummy data generator capable of producing fake addresses, names, phone numbers, etc. Mock servers can be generated from a series of tightly coupled requests and the corresponding response examples. Instead of using the default saved example, you can customize the response to fit your needs. Below is a screenshot of a saved example from the request that gets all books from a library:
In this case, this is obviously not sensitive data. But if the author and id fields were something like name and credit card number, this could be information you’d rather simulate in a sensitive environment. Or if the developers just want to work with non-static data to simulate a real workflow, dynamic variables can be used.
By editing the response example to contain dynamic variables, we can enable our mock server to take advantage of the built-in Faker.js library and provide dummy data. In the video below, we show you an example of returning random colors from a mock server endpoint:
The internet is an unpredictable place—let mocks bring order to your development lifecycle
In sports, a common refrain is to “control the controllables.” This generally means focusing your energies on the things you can do to shape the outcome of an even—like your attitude and effort.
With the aid of mock servers, a similar mindset can be adopted for development. While we can’t control the stability of an external API, we can use a mock server to simulate what should happen, reducing confusing or unexpected hiccups along the way. Let mock servers be the stability you need to do the work you want.
For some hands-on practice and exploration of mocks, check out this Mock Services collection for day 10 of the 30 Days of Postman coding challenge for developers.
Technical review by Arlemi Turpault.
What do you think about this topic? Tell us in a comment below.