Why Front‑End/Back‑End Separation Matters: Practical API Guidelines for Modern Web Apps

1. Introduction

With the rapid growth of the Internet, front‑end pages have become more flexible and visually rich, while back‑end services demand high concurrency, availability, performance, and scalability. However, the lack of a unified interface contract often makes front‑end/back‑end integration consume 30%‑50% of project effort, becoming a soft spot in product development.

2. Why Separate Front‑End and Back‑End

The traditional "backend‑centric MVC" model (see diagram) improves code maintainability by clearly assigning responsibilities, but front‑end development still heavily depends on the backend environment, leading to low efficiency and tangled responsibilities. Two typical collaboration modes illustrate these issues:

Front‑end builds a demo, then backend wraps it with a template (e.g., early Taobao). Fast local development but costly template integration.

Front‑end handles both browser UI and server‑side view templates (e.g., Alipay). UI code stays with front‑end, but development is still bound to backend environment.

These patterns result in heavy front‑end reliance on backend, unclear division of duties, limited front‑end capabilities, and difficulty applying advanced performance techniques.

3. What Separation Means

The first stage of front‑back separation is the SPA era driven by Ajax (see diagram). The key collaboration point becomes the Ajax/JSONP interface. Although the complexity shifts from server‑side JSP to client‑side JavaScript, a layered architecture on the browser (see diagram) emerges, similar to Spring MVC.

Key challenges in this stage include:

Strict front‑back interface contracts.

Controlling front‑end development complexity.

4. How to Implement Separation

4.1 Responsibility Separation

Front‑end and back‑end communicate only via asynchronous interfaces (AJAX/JSONP).

Each side has its own development workflow, build tools, and test suites.

Separation of concerns makes the two sides relatively independent and loosely coupled.

4.2 Development Process

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 documentation, optionally using a mock platform.

After development, perform joint debugging and submit for testing.

4.3 Concrete Implementation

API documentation server that synchronously pushes changes to the front‑end.

Mock data platform that provides real‑time mock responses.

Well‑defined API specifications (see Section 5) that directly affect front‑end workload and logic.

5. API Specification v1.0.0

5.1 Specification Principles

Response data is directly rendered; front‑end only handles rendering logic.

Rendering logic must not span multiple API calls.

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

Data format is JSON, kept lightweight; avoid deep nesting.

5.2 Basic Format

5.2.1 Request Format

Both GET and POST requests must contain a body parameter that wraps all request data as JSON.

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

5.2.2 Response Format

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

200 – success

500 – failure

401 – unauthenticated (redirect to login)

406 – unauthorized (show unauthorized page)

5.3 Response Entity Format

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

5.4 Response List Format

data.list

contains an array of list items.

5.5 Response Pagination Format

{
    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
    }
}

recordCount – records on the current page

totalCount – total records

pageNo – current page number

pageSize – size per page

totalPage – total pages

5.6 Special Content Specification

5.6.1 Dropdown, Checkbox, Radio

Selection state is determined by the back‑end via an isSelect flag.

{
    code: 200,
    data: {
        message: "success",
        list: [
            {id: 1, name: "XXX", code: "XXX", isSelect: 1},
            {id: 1, name: "XXX", code: "XXX", isSelect: 0}
        ]
    }
}

5.6.2 Boolean Type

Use 1 for true and 0 for false in JSON.

5.6.3 Date Type

Represent dates as strings; the exact format depends on business requirements.

6. The Future of Front‑End

The current separation model belongs to the first SPA stage, which still relies on jQuery and results in complex page rendering. The next stage will emphasize front‑end‑centric MV* frameworks, improving reusability. Ultimately, the “full‑stack Node era” will let the front‑end control routing and UI, while the back‑end becomes a pure data and business service focused on high availability and concurrency.

7. References

https://www.zhihu.com/question/28207685 http://taobaofed.org/ http://2014.jsconf.cn/slides/herman-taobaoweb http://blog.jobbole.com/65509/ https://blog.kaolafed.com/ http://blog.jobbole.com/65513/ http://blog.jobbole.com/65534/ http://blog.jobbole.com/65541/ http://blog.jobbole.com/56161