Guidelines for Front‑End/Back‑End Separation and API Specification

With the rapid development of the Internet, front‑end pages have become more flexible and interactive while back‑end services demand higher concurrency, availability, performance, and scalability. However, the lack of a unified interface contract makes front‑end/back‑end integration consume 30%‑50% of project effort.

Historically, the "backend‑centric MVC" model forced front‑end developers to rely heavily on back‑end templates (Velocity, Freemaker) and resulted in tangled responsibilities, such as back‑end‑driven routing and business logic embedded in controllers. Two typical collaboration modes emerged: (1) front‑end builds a demo then back‑end wraps it with a template, and (2) front‑end handles both view and server‑side templates, each with its own drawbacks.

The proposed separation emphasizes clear responsibility division: both sides communicate only through asynchronous interfaces (AJAX/JSONP), maintain independent development workflows, and keep concerns loosely coupled. This enables faster iteration, better focus on each domain, and reduces coordination overhead.

To implement the separation, the article suggests a concrete process: back‑end maintains API documentation, updates it on changes, and implements the interfaces; front‑end uses the documentation (and a mock platform) for parallel development; after implementation, both sides perform joint testing and integration.

It then defines an API specification (V1.0.0) covering principles (front‑end only renders, JSON payloads, simple data structures), request format (all parameters wrapped in a {"body":{...}} JSON object, e.g., GET /login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1} ), response format (standard {"code":200,"data":{"message":"success",...}} with status codes 200, 500, 401, 406), entity and pagination structures, and special handling for dropdowns, booleans (1/0), and dates.

Finally, the article looks ahead to the "front‑end‑centric MV* era" and the eventual "full‑stack Node era", where the front‑end controls routing and controllers while the back‑end serves only data and business logic, and provides a list of reference materials for further study.