Guidelines for Front‑Back End Separation and API Specification

With the rapid evolution of the Internet, front‑end pages have become more dynamic and demanding, while back‑end services require high concurrency, availability, performance, and scalability. This divergence often leads to a lack of clear interface contracts, causing front‑back end integration to consume 30%‑50% of project effort.

The author argues for a contract‑first approach to reduce unnecessary communication overhead, enabling each side to focus on its expertise. Two historical collaboration models are described: (1) front‑end builds a demo that back‑end wraps with templates, and (2) front‑end handles both browser‑side development and view‑layer templating. Both have drawbacks that motivate a clearer separation.

The proposed first stage is the AJAX‑driven SPA era, where the key collaboration point is the asynchronous interface (AJAX/JSONP). The article stresses the importance of stable, well‑defined APIs and suggests using tools like API Blueprint or internal platforms for interface documentation and mock data generation.

Implementation steps include:

Back‑end maintains API documentation and updates it on changes.

Back‑end develops APIs according to the documentation.

Front‑end consumes APIs and uses a mock server for parallel development.

Joint integration testing and submission.

API specifications (v1.0.0) are detailed, covering request formats (GET/POST with a body JSON payload), response structures (standard code , data.message , and optional entity , list , or pagination fields), and special handling for dropdowns, booleans, and dates. Status codes 200, 500, 401, and 406 are defined with corresponding meanings.

Future directions point to a front‑end‑centric MV* era and eventually a full‑stack Node.js era, where the front‑end controls routing and the back‑end serves only data and business logic.

Reference materials and further reading links are provided at the end of the article.