How to Intercept HTTP Requests for Frontend Mocking Without Cross‑Domain Issues

Common Methods and Issues

The most straightforward approach is to maintain a static mock server that returns predefined mock data, but managing such data becomes cumbersome. A better solution is an API Management Platform (AMP) that can generate mock data from interface definitions and also act as a proxy, forwarding requests to the real backend when an interface is completed.

However, when interfaces require role‑based authentication, browsers do not send cookies on cross‑origin requests, causing the proxy to lose authentication information. Existing workarounds such as adding login simulation to AMP or using browser extensions are either inflexible or costly.

Based on HTTP Request Interception

The proposed method intercepts HTTP requests at the browser level, decides whether to return mock data or forward the request to the real server, and preserves cookies, thus solving the cross‑origin authentication problem without invasive code changes.

Main Innovations

Intercepts XMLHttpRequest and fetch at a low level, independent of browser type or JavaScript libraries.

Implements the proxy entirely in the front end, keeping login information intact and avoiding extra authentication handling.

Provides a fast, plug‑in‑style usage that can be easily added or removed.

Design Idea

Web front‑end development uses JavaScript, and HTTP requests are made via the Fetch API or XMLHttpRequest. The solution wraps these native APIs, preserving their original methods and properties, and injects interception logic (ApiProxy) that can be configured for different request patterns.

Implementation

First, the native XMLHttpRequest and fetch objects are saved. New APIs with the same names are created, copying all original methods and properties. In the overridden open and send (for XHR) or the outer Promise (for fetch), the request is paused, parameters are extracted, and a query is sent to AMP to determine the interface status.

ApiProxy Workflow

Register an interceptor that captures HTTP requests and parses identifying parameters (domain, method, path).

Use these parameters to query AMP for the interface definition and development status.

If AMP indicates the interface is still under development, it returns mock data; otherwise it returns a special flag.

ApiProxy checks the flag: if mock data is returned, it supplies it directly to the original request; if the flag indicates completion, the original request is sent to the real backend, preserving all cookies and authentication.

Different Request Types

For XMLHttpRequest, interception occurs in the send method because the request body is only available there. The parameters are stored, the real send is delayed, and AMP is queried before deciding whether to proceed.

For fetch, a wrapper Promise pauses the request, queries AMP, and either resolves with mock data or allows the original fetch to continue.

Starting the Front‑End Proxy

In practice, a bundler like Webpack can include a configurable plugin that injects the proxy code into the main page during development, enabling the proxy with a single configuration.

Conclusion

The front‑end proxy method pushes proxy responsibilities to the browser, eliminating extra steps through mock servers or AMP, preserving role‑based authentication, and avoiding browser‑specific plugin issues. By intercepting HTTP requests at a low level, developers can quickly switch between mock and real data and integrate the solution via standard build tools.

Figure 1: Interaction flow between the proxy, AMP, and the backend service.

Figure 2: Core working principle of the proxy.