Mocking HTTP responses

Use an OpenAPI contract to mock HTTP responses to API calls.

Please enter the simulation

wiretap can be used as a full simulation of a real API. We call it mock mode.

To enable it, use the -x or the --mock-mode flags when running wiretap with an OpenAPI Specification.

wiretap -s giftshop-openapi.yaml -u -x

Try before you buy

mock mode simulates a real, working web API by using an OpenAPI contract to simulate the responses to API calls.

The simulation is based on the OpenAPI contract, which means the API will be contractually correct, ideal for testing and development. Developers can use the mock API to test their code, without having to wait for the real API to be built. mock mode also allows developers to test their code against different scenarios, such as error responses, or slow responses.

mock mode helps developers ensure a client is fully compliant with an API, before the API is even built.

Call it a client, call it a UI - whatever you call it, mock mode helps developers ensure a client is fully compliant with an API, before the API is built. The backend does not need to exist, as long as you have a valid OpenAPI specification, you can use mock mode to simulate the API.

But why?

API First / Design First development is a great way to build APIs. It’s a great way to build clients and UIs too. The API contract is designed first, taking in to consideration all the requirements of consumers of an API, by having the consumers involved in the design.

It allows us to answer questions upfront like:

  • Does the API contain all the data and information a client will need?
  • Are the data models designed so the client can use them easily?
  • Does the UI need to make 500 calls to extract a single page of data?
  • Has security, pagination, rate limiting, etc. been considered?
  • What happens when the API returns an error?

Answer all of these questions up front with a working API to play around with designs and ideas, without having to write a single line of backend code.

Avoid making costly mistakes to a production API, by trying out new designs and ideas in a mock API first.

Why use wiretap?

Similar functionality is available in other tools, such as Stoplight Prism. However, there are some advantages of using wiretap for mocking over other tools:

  • Much faster than Prism, and other tools.
  • Has more features, like static hosting, path rewriting the monitor UI and more.
  • Distributed as a small single binary, no dependencies, no runtime.
  • Lightweight, uses less memory and CPU than Prism, and it’s only 22mb.

How does it work?

When enabling mock mode, wiretap will use the OpenAPI contract to simulate the responses to API calls, before it does this however, it will validate the request against the contract, and if the request is invalid, it will return an error response.

wiretap will also try to locate an appropriate error message in the OpenAPI contract, and return that, otherwise it will return a wiretap specific error message that contains details of what went wrong.

Here is a high-level flow of the logic used to decide what do to with an incoming request, when in mock mode.

Flow diagram of wiretap's mock engine logic.
High level overview of wiretap’s internal mock engine handles requests.

Any error that is output in a red box, is an error generated by wiretap itself, and not the OpenAPI contract. When there is no representation of that error in the OpenAPI contract, wiretap will return an RFC7807 compliant error response that has been generated with a relevant HTTP code and a wiretap specific error message.

A good way to find gaps in an API contract, is to have wiretap generate errors for you. It may get messy!

Multiple examples

When a suitable response is found, and there are multiple examples for that response, wiretap will select the first one it finds, which could be any of them, but it’s generally the first one loaded in from the spec.

Preferred examples

If a preferred example is desired for a specific API response, wiretap can be informed to select a specific example by name using the Preferred header.

For example if we have a MediaType with two different examples defined something like this:

      summary: "A product to create"
        name: "pb33f t-shirt"
        description: "A t-shirt with the pb33f logo on it."
        price: 19.99
        category: "shirts"
        image: ""
      summary: "Another example"
        name: "pb33f hat"
        description: "A baseball cap with the pb33f logo on it."
        price: 29.99
        category: "hats"
        image: ""

And we want to extract the SomeOtherExample example, we can use the Preferred header to tell wiretap to use that example.

curl "https://localhost:9090/some/api/endpoint" -H "Preferred: SomeOtherExample"

Override response code

If you want to override the response code that wiretap will return, set a header named wiretap-status-code with the HTTP response code you want to return.

The return code of your mock will then reflect this value and override what ever is defined by the OpenAPI specification.

This will allow you to test how your client handles different response codes with successful mock responses.

Only works when a successful mock response is generated. Available from wiretap version v0.1.11