Mocking APIs Made Simple: Pain Points, Solutions & Best Practices with EchoAPI

In everyday API development, mocking is almost unavoidable. Whether it’s fast iteration at the early stage of a project or when an endpoint isn’t ready yet, mocking ensures front-end development continues smoothly—even without real backend data.

1. Real-World Pain Points

Imagine this scenario:
You’re building a front-end for an e-commerce site. When a user clicks "Pay Now," your front-end calls the backend /pay endpoint, which should return something like:

{
    "data": {
        "code": 0,
        "message": "success",
        "pay_dtime":"2025-08-10 10:00:00",
        "order_id":"sn12345678"
    }
}

But the problems are:

• The backend isn’t ready, so you can’t test the post-payment flow.
• The payment API depends on an external gateway, not configured in the test environment.
• Some endpoints require complex authentication or data prep, making them unusable early.

Waiting on backend development blocks front-end progress—this is where mocking becomes critical.

2. Common Mocking Approaches & Limitations

2.1 Local JSON Files

Simplest approach: create mock/data.json and fetch it:

fetch('/mock/pay.json')

Drawbacks:

• Data is static; cannot simulate multiple scenarios.
• Cannot handle complex logic like pagination or conditional queries.

2.2 Front-End Request Interception (axios-mock-adapter, Mock.js)

Intercept requests in the browser:

mock.onPost('/api/pay/confirm').reply(200, {
  "data": {
    "code": 0,
    "message": "success",
    "pay_dtime":"2025-08-10 10:00:00",
    "order_id":"sn12345678"
  }
});

Drawbacks:

• Only usable within the front-end project.
• Data hardcoded in code; hard to maintain.

2.3 Self-Hosted Mock Server (json-server, Easy Mock)

Run a separate mock service:
Drawbacks:

• High setup and maintenance cost.
• Complex logic requires extra scripting; flexibility is limited.

These methods work for basic needs but lack flexibility and dynamic data generation as project complexity grows.

3. EchoAPI Mocking in Practice

EchoAPI offers a flexible and modern solution, supporting both rapid development and complex scenarios. Let’s take /pay as an example.

3.1 Fixed-Value Mock

Simulate a fixed response:

{
  "data": {
    "code": 0,
    "message": "success"
  }
}

In EchoAPI, create a POST /pay API, define the response visually:

Then switch to the Mock tab to get the generated Mock URL:

Calling this URL returns the predefined response:

3.2 Randomized Values

Add dynamic fields like pay_dtime. EchoAPI has built-in variables to generate random or time-based values:

{
  "data": {
    "code": 0,
    "message": "success",
    "pay_dtime":"2025-08-10 10:00:00"
  }
}

Just insert a built-in date variable:

Example response:

Now each request returns fresh data, avoiding static JSON limitations.

3.3 Custom Functions

For highly customized fields, like order_id starting with sn followed by 8 digits:

{
  "data": {
    "code": 0,
    "message": "success",
    "pay_dtime":"2025-08-10 10:00:00",
    "order_id":"sn12345678"
  }
}

Use EchoAPI’s custom function:

Create fn_orderno using AI or manual logic:

Response example:

3.4 Conditional Responses

Handle multiple scenarios: success, insufficient balance, account locked. Set expectations for "insufficient balance":

Returned response:

This approach is far closer to real-world behavior than static JSON.

4. Summary

Mocking is essential for front-end efficiency:

• Front-end can develop independently of backend readiness.
• QA can reuse mock links to test early.

EchoAPI Advantages:

• Built-in variables: generate diverse data quickly.
• Custom functions: implement complex business logic, AI-assisted if needed.

Whether you need rapid iteration, independent development, or realistic scenario simulation, EchoAPI delivers a flexible, professional, and time-saving solution that keeps your projects moving forward seamlessly.