Using mocked HTTP API responses to speed up the development of client applications
One of the usual causes of delays for delivery as a Frontend engineer is usually pending work from backend services. Either the API for the HTTP request itself is not complete or the trouble you might have to go through to simulate different use cases for the API e.g when the HTTP request fails with a certain status code, a different response depending on the user making the request e.t.c Having several of these delays over time can pose a significant reduction in the pace of how fast a Frontend engineer can deliver a feature.
One method that has worked for me in tackling these issues is simply using API mocking. API mocking involves an environment that mimics or simulates the behavior of an API. This would allow you to test and develop applications without relying on real data
The way HTTP mocking works is that you can set up a server called a mock server that can listen to requests from the client application. On the mock server, you can specify a modified response, also called a mocked response that can be returned for a a request from the client application. If there is no mocked response for an HTTP request from your application, then the request proceeds as normal to your backend server.
Mocking HTTP requests while developing a client application provides many benefits. I will mention some below.
Prototyping API changes without needing to make changes to backend services
By mocking HTTP responses, you can test and prototype potential new changes for a backend service API without needing to make those changes to the actual service. This can save some engineering time as if that change ends up to be not needed after testing, no time would have been wasted to write code on the backend service as well as the client application.
Faster testing for multiple cases for an API
When working with APIs for integration on a client application, there are usually many scenarios that need to be considered for the API, but just to name a few;
when the request to the API fails
when there is no resource available from the API
when the resource returns different status codes
Testing all the scenarios depending only on the API server can be time-consuming. One practice I have seen is the code for the API on the server being modified on different staging or testing environments. Using a mock server can simplify this process and it means client developers can quickly adjust rules to meet the requirements for a use case they want to test without requiring any work from backend server developers.
Working in parallel with the development of a new API or changes to an existing API
One case I have run into a lot of times when working on a new feature that also requires integration with a backend service is having to wait for the API development to be ready. Sometimes midway through the integration, there could be discoveries of missing features that need to be added to the API or bugs that need to be fixed. All this could mean that the backend development could block client development multiple times. Using API mocked can help client developers continue with development while the development of the API on the backend service is underway.
Several tools can be used to mock HTTP requests, but I will share two (2) I use for development daily. They are simple tools and are to be used on browsers.
tweak: tweak is a browser extension that allows you to mock HTTP requests by defining a set of rules that can capture HTTP requests from your application and return a mocked response.
With tweak, you can specify rules which can include the URL of an HTTP request you want to mock, the status code, a delay and also the response payload. It makes it very easy to quickly test multiple cases for an HTTP request on the fly. How it works is that tweak listens for outgoing HTTP requests and matches them against the rules you specify. If there's a match for the request, tweak will return the mocked response. The extension is available on the extensions store for all major browsers.
Chrome DevTools: If you use any Chromium-based browser, you can make use of the Network DevTools to override web content and HTTP response headers locally.
With local overrides, you can override HTTP response headers and web content, including XHR, and fetch requests to mock remote resources. The way it works is that when you specify an override for an HTTP request, DevTools creates and saves a file to a folder you specify. This file contains the content of the mocked response. When you reload the page, DevTools serves the local file, rather than the network resource. You can find more details on how to use this feature here in the Chrome for Developers docs.