Introduction
A mock API is designed to imitate a real API by providing a realistic mock data response upon request. A well designed mock API will reliably respond to requests with static or dynamic data that matches the real API schema including data types, objects and arrays.
Why Mock the API?
A mock API server is useful during development and testing when live data is either unavailable or unreliable. Whilst co-designing the production API, the development team can use a mock API to unblock concurrent work on the frontend and backend, and to gather feedback in user research, testing, and in stakeholder playbacks.
During development the frontend team will likely move a lot faster than the backend team can implement the real API. A mock API overcomes this issue as the frontend can consume a working API with the same interface as the eventual production API. As an added benefit, the backend team can discover where the mock API doesn’t meet the developer’s needs without spending dev time on features that may be removed or changed. We’ve found this fast feedback loop makes engineering teams much more efficient.
A mock API is also useful when unit testing. Usually our tests will run alongside a deployment, and waiting for calls to a live API is inefficient. A mock API server can return anticipated results so we can unit test the rest of the codebase without delays or reliance on an external resource.
The value of maintaining an API Specification
The mock and production APIs often evolve over time as shared understanding emerges throughout the project. To ensure that API servers are kept up to date, we’ve found it really helps to maintain a detailed API specification.
At Thinkmill this specification forms the blueprint for the API, and frontend and backend developers view it as an agreed upon contract as to how the application and API layers will communicate. We assume that if it’s not in the specification, it doesn’t exist.
While writing and maintaining specs aren’t a lot of fun, luckily there are tools that make it much less of a chore. For REST APIs the tool to use is OpenAPI Specification (Swagger), essentially a YAML file that details each endpoint and its response.
Participants
We’ve found that the creation of a Mock API is best led by a Technical Architect as they’re the person most capable of obtaining a detailed view on how the project’s underling API will need to be structured.
It’s often a good idea to include a Design Lead or UX Designer in support to help inform how the data structures might overlap with any pre-existing mental models that the users and business might hold.
The API specifications can play a valuable role for designers/product owners when sparring on features. Being able to understand the available data sources, and including references to the data types helps the team make informed design decisions that benefit both user experience and application performance.
How to setup a Mock API server
For step-by-step instructions on how to setup a Mock API using Storybook and Mock Service Worker, see our article Storybook and Mock APIs: A Powerful Prototyping Combo.
