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

The rapid growth of the Internet has made front‑end presentation and interaction increasingly sophisticated while back‑end services demand high concurrency, availability, performance, and scalability, leading to a growing gap between front‑end and back‑end development.

Without clear interface contracts, front‑end and back‑end teams often spend 30%‑50% of project effort on integration, making the integration phase a major bottleneck.

The article advocates a separation‑first approach to reduce unnecessary communication and allow each team to focus on its expertise.

Why Separate

Traditional back‑end‑centric MVC architectures improve code maintainability but still suffer from heavy front‑end dependence on back‑end environments, tangled responsibilities, and limited front‑end performance optimization.

Front‑end development efficiency is low due to heavy reliance on back‑end environments. Responsibilities of front‑end and back‑end remain entangled. Front‑end capabilities are limited by back‑end constraints.

What Separation Means

The first stage of separation is the SPA era driven by Ajax, where the key collaboration point is the Ajax interface; however, complexity shifts from server‑side JSP to client‑side JavaScript.

How to Achieve Separation

4.1 Responsibility Separation

Both sides communicate solely via asynchronous interfaces (AJAX/JSONP) and maintain independent development processes, tools, and testing suites, achieving loose coupling.

Backend provides data and business logic; Frontend consumes data and handles rendering.

4.2 Development Process

Backend maintains API documentation and updates it when interfaces change.

Backend implements the interfaces.

Frontend develops against the documentation, optionally using a mock platform.

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

Mock servers can automatically generate mock data from the API documentation.

4.3 Implementation

Implemented components include an API documentation server, a mock data platform, and a set of interface standards (see Section 5).

5. API Specification V1.0.0

5.1 Principles

API responses contain all data needed for rendering; the front‑end only handles presentation.

Rendering logic must not span multiple API calls.

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

Data is transferred as simple JSON.

5.2 Basic Formats

5.2.1 Request Format

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

Example GET request:

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

POST requests follow the same principle (illustrated by an image in the original article).

5.2.2 Response Format

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

code indicates processing status (200 = success, 500 = failure, 401 = unauthenticated, 406 = unauthorized). data.message provides a human‑readable message.

5.3 Entity Response

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

5.4 List Response

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

5.5 Pagination Response

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

5.6 Special Content Rules

5.6.1 Dropdown, Checkbox, Radio

Selection state is determined by the back‑end using 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

Booleans are represented as 1 (true) or 0 (false) in JSON.

5.6.3 Date Type

Dates are transmitted as strings; the exact format depends on business requirements.

6. The Future of Front‑End

The current separation model is the first stage; future work will focus on front‑end engineering, modular reuse, and eventually a full‑stack era where the front‑end controls routing, controllers, and URLs, while the back‑end serves only data and business services.