The Chaotic Evolution of API Design: From Early AJAX to Post‑Restful Practices

1. The Wild Early Days

When AJAX first appeared, the team agreed on a simple JSON response format:

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

HTTP status code 200 was used to indicate a healthy backend, but error codes were inconsistent, with only 401 meaning authentication expiration while other errors were vague.

2. The Architect Arrives

The architect advocated proper Restful practices, aligning with standard HTTP status codes such as 200 OK, 400 Bad Request, 401 Unauthorized, 403 Forbidden, and 404 Not Found. However, as the team grew, the Restful conventions began to break down.

2.1 HTTP Error Codes Are Not Enough

The architect suggested using custom codes like 601, but HTTP status codes are limited to three digits, causing values like 2001 to be truncated to 200, turning errors into successes.

2.2 Resource Boundaries Are Messy

Questions about where to place login resources led to the creation of numerous pseudo‑resources such as _log and login_log , some backed by real tables, others only to satisfy Restful naming.

3. The Architect Leaves

After the architect disappeared, the project faced new issues: 404 responses were hijacked, and the team resorted to HTTPS without proper handling.

3.2 Mini‑Program Constraints

WeChat mini‑programs do not support the PATCH method, so a _method parameter was added to POST requests to indicate a PATCH operation.

4. Post‑Modern Renaissance

Eventually the team abandoned Restful standards and adopted a POST‑only strategy for all parameters (except downloads and exports). The response format reverted to a simple JSON structure:

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

New status code rules kept 200 for success while allowing hierarchical codes like 4031 for specific permission errors, using a unified enumeration.

4.4 New Interface Naming Standard

Endpoints now follow the pattern verb + adjective + resourceName , e.g., getUserInfo , updateOrderStatus , addMyOrder , or deleteAllLog , making the purpose of each API clear from its URL.

5. Conclusion

The story is not about judging good or bad practices but sharing a real‑world experience of how API design can devolve and the importance of consistent standards.