Front‑Back End Separation: Principles, Practices, and API Specification (v1.0.0)

With the rapid growth of the Internet, front‑end pages have become more dynamic and demanding, while back‑end services require high concurrency, availability, performance, and scalability, leading to a growing gap between front‑end and back‑end development.

Because the two sides often work without clear interface contracts, integration can consume 30‑50% of project effort, making interface coordination a major bottleneck.

The article first motivates the need for separation, then reviews the traditional back‑end‑centric MVC model and its limitations, followed by the SPA era driven by Ajax where the key collaboration point is the Ajax interface.

It proposes a clear separation strategy:

Both sides communicate only through asynchronous interfaces (AJAX/JSONP).

Each side maintains its own development process, build tools, and test suites.

Focus on concerns separation to achieve loose coupling.

The recommended development workflow includes:

Back‑end writes and maintains API documentation; updates it when the API changes.

Back‑end implements the API according to the documentation.

Front‑end develops against the API, using a mock platform for parallel work.

After development, both sides perform integration testing and submit for QA.

A mock server can generate mock data from the API documentation, enabling true API‑as‑code.

The API specification (v1.0.0) defines several principles: responses should directly drive rendering, avoid cross‑API calls in the front‑end, keep business logic out of the UI, use simple JSON payloads, and standardize status codes.

Basic request format (GET/POST) requires a body parameter containing JSON, e.g.:

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

Standard response format:

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

Entity response example:

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

Pagination response example:

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

Special content rules include using a unified isSelect flag for dropdowns, checkboxes, and radio buttons, representing booleans as 1/0, and transmitting dates as strings.

The article concludes with a look ahead to the "front‑end‑centric MV* era" and the eventual "full‑stack Node era" where the front‑end controls routing and the back‑end serves only data and business logic.

References to further reading are provided.