Creating a Mock API Service - 6 Questions You’ll Need to Answer

APIs are the glue that hold modern applications together, but developing against them can get tricky. The more microservices and 3rd party APIs you introduce, the more dependencies you’re juggling. And if an internal or external APIs is offline, not ready yet, or changing, it can slow down your development and testing.

When multiple teams depend on multiple APIs – and when it becomes clear that dependencies are slowing you down – you might decide you need some kind of API mocking capability. And since simulating a few HTTP requests sounds simple enough, many opt to roll out their own solution rather than using an established tool.

While this path is certainly viable, in this article we’d like to point out that it’s harder than you think - or at the very least, illustrate some of the challenges you’ll need to address if you’re going the DIY route.

Wait, is this a sales pitch? Yes and no. You’re reading this on the WireMock Cloud blog. We developed a cloud mocking platform because we think API mocking is a problem that requires undifferentiated heavy lifting to solve internally (which makes cloud tooling the better choice). For those that do prefer to build rather than buy, there’s always open source WireMock. Either way, it’s good to be aware of the types of problems you might encounter.

‍

6 questions to ask about your mock API service

1. What happens when you move from unit to integration testing?

Let’s say you’re building an ecommerce store that includes a catalog service, shopping cart, and billing service which uses an external payment gateway API. In unit testing, you might test the billing service against the payments API in isolation. But in integration testing, you’ll want to see how everything comes together - simulating the full journey of a user making a purchase on the website and how all these microservices and external APIs function under various conditions.

In the unit testing scenario, you can get by with mocking the API gateway on your local machine. But once you move to integration testing, you need a way of hosting that service. To communicate with the rest of your app, it needs to run on the network, be reachable via an IP address, and have a DNS name.

Configuring and deploying a new service in your environment is always going to involve an engineering effort. Setting up all the infrastructure for a service which, by definition, will never be used for anything customer-facing is a questionable use of engineering resources

2. What’s your plan for HTTPS and SSL?

The services that make up your app are probably configured to communicate over HTTPS. This leaves you with 3 options when it comes to your mock service:

1. Get a proper, CA-signed SSL certificate, which clients will trust by default
2. Get a self-signed certificate, and configure your clients to trust it
3. Temporarily switch off SSL verification for the duration of your tests

The problem with option 1 is that it adds a lot of overhead in acquiring the certificate and implementing the associated infrastructure to protect and rotate keys. Options 2 and 3 are simpler, but they will require a lot of configuration and reconfiguration - this adds its own overhead, and also makes your tests less realistic. (Ideally you want to run an integration test with the same configuration clients will use when the service is live.)

3. How do you edit mocked responses?

If you’ve rolled out something yourself - either developing from scratch or using a headless open source tool - changing a running service is not straightforward. If you want to simulate a different type of response, you’ll need to modify the source code, rebuild the service, and deploy the new version. 

Some open source software might offer a better way to do this, but there is a learning curve that comes with any open source tool. Again, you are expending resources - in this case engineers spending time to master a framework - on internal tooling that can accelerate internal processes, but at the end of the day does not make your app more valuable to customers.

You should also consider the speed of deploying these changes and seeing them in your tests. With a cloud service, updates are usually instantaneous. With a self-hosted solution, you have to wait for the service to be redeployed along with its dependencies. This can delay your testing, and ultimately your release cycle, much more than you’d like.

4. Do you have the log review, verification, and debugging tools you need?

When you’re troubleshooting your mock service, you need to be able to review logs and verify that the service is returning the expected responses. This is not always simple, as mocking often requires a deep view of every request and response in order to troubleshoot. The logging infrastructure you use for other components in your app might not suffice.

When you’re creating separate tools to debug a tool you’ve created for testing purposes, you’re two layers deep into undifferentiated heavy lifting. Not ideal.

5. APIs can and will change. How will you keep the mock in sync?

When you’re mocking a third-party API, or even an internal one, the mocked API’s design can change with little warning (such as due to a new version being released, an endpoint being discontinued, or a change to the response JSON structure). 

You need to be able to keep your mock API in sync with the real one if you want your tests to stay reliable. For homegrown solutions, this might require coding and deploying an updated version of your mock service. You’ll end up delaying development to give testing time to catch up.

6. How do you support collaboration around mocked APIs?

If you’re developing a large application, there will be multiple teams involved, and potentially dozens of APIs. You’ll want to ensure that different teams are developing against the same set of mocks by default, while also enabling collaborators to modify an existing mock in order to simulate a certain category of responses or scenarios. You’ll also need to be able to share the responses.

Building this type of collaborative mock repository will also force you to solve issues around versioning, access control, and permissions – adding engineering overhead that could be outsourced to a cloud service.

+ Everything else that goes into building software

Like any other piece of bespoke software your team is responsible for, the API mocking service must be maintained over time: bug fixes, security patching, new features. 

This means that you’ll need developers to maintain an understanding of how this piece of software is deployed, modified, and tested. You’ll need this knowledge to be documented and maintained in case of personnel changes. Like any other part of your codebase, it will grow larger, more complex, and more entrenched over time – creating a consistent resource drain on developer hours that could be better used elsewhere.

How WireMock Cloud Solves All of This

WireMock Cloud exists to provide a productive, secure and constantly improving platform that minimizes the effort your team needs to expend on undifferentiated activity. Here’s how you would answer these questions if you were using WireMock Cloud:

1. Hosting: WireMock Cloud is hosted and managed by WireMock, so there is no need to provision infrastructure, create deployments or configure DNS..
2. HTTPS: WireMock Cloud mock APIs are served with up-to-date, CA signed TLS certificates so your HTTP clients will trust them without modification.
3. Editing mocked responses: The web UI supports instantaneous edits to mock API stubs.
4. Logging: The WireMock Cloud UI has a detailed, browsable request log for each mock API.
5. Dealing with API changes: We’ve implemented OpenAPI import, which means keeping up with changes is closer to a copy and paste job, rather than a ‘back to the drawing board’ problem.
6. Collaboration: WireMock Cloud is built expressly for team members to concurrently edit and use mock APIs. It supports fine-grained sharing and access controls (individual users + teams) for mock APIs and other resources.

If you’re still unsure, use WireMock Cloud for free - all you need is an email address or GitHub account, and you get access to the free-forever edition which includes up to 1,000 API calls a month. Try it out and see how it compares to building in-house; or feel free to join the Slack community and ask any questions you might encounter along the way.