Guidelines for Frontend‑Backend Separation and API Specification

1. Introduction

With rapid internet development, front‑end pages become more flexible and interactive, while back‑end services demand high concurrency, availability, performance and scalability, leading to a separation of concerns between front‑end and back‑end teams.

2. Why Separate

Two typical collaboration models are described: (1) front‑end builds a demo and back‑end wraps it with a template, which causes heavy communication overhead; (2) front‑end handles both view and template, reducing back‑end involvement but still tightly coupling to back‑end environments.

3. What Separation Means

In the SPA era, the key integration point is the Ajax/JSONP interface. The article stresses the need for clear interface contracts, mock servers, and stable data formats to reduce integration effort.

4. How to Achieve Separation

4.1 Responsibility Separation

Front‑end and back‑end communicate only through asynchronous interfaces; each side maintains its own build and test pipelines; concerns are separated to achieve loose coupling.

4.2 Development Process

Back‑end writes and maintains API documentation; front‑end uses the docs and mock data for parallel development; after implementation, both sides perform joint testing.

4.3 Implementation Details

Introduce an API documentation server and a mock data platform; define strict API specifications (see section 5).

5. API Specification V1.0.0

5.1 Principles

Response data is directly rendered by the front‑end.

Rendering logic must not span multiple interfaces.

Front‑end focuses on interaction and rendering, avoiding business logic.

All data is transferred as simple JSON.

5.2 Basic Formats

5.2.1 Request Format

All GET/POST requests must contain a body parameter with JSON payload, e.g.:

xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}

5.2.2 Response Format

Standard response structure:

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

Code meanings: 200 success, 500 failure, 401 unauthenticated, 406 unauthorized.

5.3 Entity Format

{ "code":200, "data":{ "message":"success", "entity":{ "id":1, "name":"XXX", "code":"XXX" } } }

5.4 List Format

Data list is returned in data.list .

5.5 Pagination Format

{
  "code":200,
  "data":{
    "recordCount":2,
    "totalCount":2,
    "pageNo":1,
    "pageSize":10,
    "list":[
      {"id":1,"name":"XXX","code":"H001"},
      {"id":2,"name":"XXX","code":"H001"}
    ],
    "totalPage":1
  }
}

5.6 Special Content

5.6.1 Dropdown/Checkbox/Radio

Selection state is indicated by isSelect (1 selected, 0 not).

5.6.2 Boolean

Use 1/0 to represent true/false.

5.6.3 Date

Represented as strings, format defined per business.

6. Future Front‑End Trends

First stage: Ajax‑driven SPA; second stage: front‑end‑centric MV* era; final stage: full‑stack Node.js where front‑end controls routing and back‑end provides pure data services.

7. References

List of URLs to blogs and articles.