The Evolution and Chaos of HTTP Status Codes and RESTful API Design

The article narrates the early days of AJAX when APIs returned a simple JSON format:

{
  "code": 0,
  "msg": "SUCCESS",
  "data": DATA // {},[],null,string,boolean,number
}

Only HTTP 200 was used for success, and error handling lacked a unified standard—most errors were ambiguous, with 401 being the sole special case for authentication expiry.

An architect later introduced proper RESTful status codes (200 OK, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found), but as the team grew, custom codes like 601, 1001, and 2001 appeared, exceeding the three‑digit limit and causing truncation (e.g., 2001 became 200).

Resource boundaries also became chaotic; developers created pseudo‑resources such as _log and login_log to satisfy RESTful naming.

After the architect left, the project faced further issues: 404 responses were hijacked, and WeChat Mini‑Programs did not support PATCH . A workaround added a _method parameter to indicate the intended method.

Eventually the team abandoned strict RESTful rules, using POST for all operations (except downloads/exports) and a unified response format:

{
  "code": 200,
  "message": "SUCCESS",
  "data": DATA // {},[],null,string,boolean,number
}

The new status‑code scheme keeps 200 for success and extends categories (e.g., 4031 for “no permission to create”). Interfaces are named with a verb‑adjective‑resource pattern like getUserInfo , updateOrderStatus , deleteAllLog , making their purpose clear.