在设计后端接口的状态码和响应码体系时，我们需要考虑 HTTP 状态码与业务逻辑状态码的结合。HTTP 状态码用于描述 HTTP 请求的状态，而业务逻辑状态码（通常称为 code）用于描述应用程序特定的状态或错误。以下是一个推荐的设计方案：

HTTP 状态码

• 2xx 成功

  • 200 OK - 请求成功
  • 201 Created - 创建成功
  • 204 No Content - 无内容（通常用于 DELETE 请求）

• 4xx 客户端错误

  • 400 Bad Request - 客户端请求无效
  • 401 Unauthorized - 未认证
  • 403 Forbidden - 无权限
  • 404 Not Found - 资源未找到
  • 409 Conflict - 资源冲突

• 5xx 服务器错误

  • 500 Internal Server Error - 服务器内部错误
  • 502 Bad Gateway - 网关错误
  • 503 Service Unavailable - 服务不可用

业务逻辑状态码

成功状态码

客户端错误码

服务器错误码

示例响应格式

1
2
3
4
5
6
7

{
  "code": 0,
  "message": "Success",
  "data": {
    "exampleField": "exampleValue"
  }
}

示例错误响应

客户端错误

1
2
3
4
5

{
  "code": 1001,
  "message": "Authentication Failed",
  "data": null
}

服务器错误

1
2
3
4
5

{
  "code": 2000,
  "message": "Internal Error",
  "data": null
}

状态码与业务逻辑码映射

在实际开发中，可以将 HTTP 状态码和业务逻辑码结合起来使用，以便前端开发人员和 API 用户能够明确地知道发生了什么问题。例如：

• 请求成功

  • HTTP 状态码：200
  • 业务逻辑码：0
  • 响应体：

    1 2 3 4 5 6 7

    { "code": 0, "message": "Success", "data": { "exampleField": "exampleValue" } }

• 参数无效

  • HTTP 状态码：400
  • 业务逻辑码：1000
  • 响应体：

    1 2 3 4 5

    { "code": 1000, "message": "Invalid Parameters", "data": null }

• 服务器内部错误

  • HTTP 状态码：500
  • 业务逻辑码：2000
  • 响应体：

    1 2 3 4 5

    { "code": 2000, "message": "Internal Error", "data": null }

这种设计使得 API 使用者能够从 HTTP 状态码了解请求的基本状态，并从业务逻辑码了解更详细的错误信息或业务状态。