Mock your API edge cases with simple proxy functionality

What you need to know:

• It’s difficult to make dependent APIs respond in a desired manner when testing an application. This is particularly true for edge cases.

• Proxying offers dev teams a potential workaround by blending mock and live API responses. 

• By proxying all but a selection of requests, it becomes possible to test errors, edge cases, and failure cases that would be difficult to replicate in the target API. 

• WireMock Cloud’s proxy functionality makes it easy to blend API responses and conduct more thorough testing on the APIs your consumer relies on. 

Edge cases are inevitable 

Your API client code must handle unexpected events without detracting from the end-user experience. At the same time, it’s extremely difficult—if not impossible—to force dependent APIs to respond in a desired manner when developing and testing an application, particularly in more challenging scenarios, edge cases, and fault cases.

Proxying to the rescue!

Proxying provides dev teams with a potential workaround for this problem. By blending mock responses with live API responses, proxying allows you to test challenging or impossible-to-reproduce behaviors in the APIs that your consumer relies upon. 

Proxying can be used to mock a certain group of requests under specific conditions while using the live APIs for scenarios we are already more confident in. This can be useful when you need to use other mocking functionality, such as testing how API-dependent code handles fault scenarios like unreliable network connections or enabling parallel development for APIs that are not ready yet. 

How proxying works in API mocking

Proxying is generally (depending on which tool you use) configured on a per-API basis. When a stub is configured to serve a proxy response, all of the normal request matching rules apply; however, instead of returning a mocked response, the request is forwarded to the target. By proxying all but a selection of requests, it becomes possible to test errors, edge cases, and failure cases that would be difficult to replicate in the target API. 

How this works on a technical level is relatively straightforward. The proxy acts as a middleman that intercepts requests. Instead of allowing these requests to reach the real API, the proxy captures them. Depending on how the proxy is configured, it’ll route the request to the real API or handle it locally to return predefined or random responses. In some cases, the proxy can also modify the requests before forwarding them to the API or modify the responses before sending them back to the client. This makes proxying incredibly useful for engineering edge case scenarios for testing purposes—for example, by altering headers, query parameters, or body content.

Using a proxy to add mocks to a real API environment

By leveraging native proxy functionality in WireMock Cloud, it’s possible to test your edge cases quickly and easily by forcing mock APIs to respond how you need them to.

The first step is to create a new stub endpoint Here, we are doing it and setting the matching criteria to ‘Any URL’. We are also setting the priority to 10, which is the lowest level. This means that if no other stubs are matched, this is the stub that will be used. 

The next step is to navigate to the Response section, where we’ll select Proxy and specify the real API to which we’ll forward the traffic. In this example, we’re using api.github.com. We’ll save this, copy our academy.wiremockapi.cloud endpoint, and open a new tab. 

In the new tab, we can make requests on the GitHub API by, for instance, asking for different endpoints. In this scenario, we’re looking at the user1, user8, and users endpoints, which all serve different responses, as shown. 

We can now head back to WireMock Cloud and look in the request log to see the three requests that have been sent through WireMock Cloud and proxied to the real API. By selecting one of the requests and converting it to a stub, we can change the way in which it responds.

In this example, we’ll convert the user8 stub and change its Status from a 404 response code with the message “Not Found” to a 200 response code with the message “ok”. 

When we navigate back to our browser and ask for user8 again, we can see that we’re no longer proxied to the real GitHub API. WireMock Cloud is responding with the stub as we’ve configured it instead. 

We can also turn this into a negative scenario. This is where using a proxy truly shines because it’s virtually impossible to reproduce negative scenarios or ask a third party to generate them for us with a live API. When user8 is requested, we'll change it to a peer connection reset fault instead of responding with a 200 response code. 

Now, when user8 is requested, we can see that the connection was reset. 

Using proxying in this way makes it easy to blend mock API responses with real API responses to test your consuming application thoroughly.

Watch Dan Perovich, WireMock Head of Sales Engineering, demonstrate the WireMock Cloud proxy functionality feature by signing into the WireMock Cloud Academy.

‍