我是否应该在RESTfulAPI中使用不同的satus代码,而不是仅使用200?

我是否应该在RESTfulAPI中使用不同的satus代码,而不是仅使用200?,rest,http,rfc,Rest,Http,Rfc,我正在开发RESTfulAPI服务。我和我的团队领导在“HTTP响应状态代码”这一主题上存在分歧 我的团队负责人说,用RFC编写的默认HTTP状态代码非常糟糕,在客户端(前端)处理它们非常困难。他认为在响应体中自定义状态代码,使用HTTP状态代码200(每次200)-是最好的方式。当尝试在没有权限的情况下执行操作时,他的响应主体将如下所示: HTTP/1.1 200 OK { code: 1005, // Custom code instead 403 data: {

我正在开发RESTfulAPI服务。我和我的团队领导在“HTTP响应状态代码”这一主题上存在分歧

我的团队负责人说,用RFC编写的默认HTTP状态代码非常糟糕,在客户端(前端)处理它们非常困难。他认为在响应体中自定义状态代码,使用HTTP状态代码200(每次200)-是最好的方式。当尝试在没有权限的情况下执行操作时,他的响应主体将如下所示:

HTTP/1.1 200 OK

{
    code: 1005,  // Custom code instead 403
    data: {
        message: "Forbidden."
    }

}

我认为这是错误的回应方式。我的应对方案如下:

HTTP/1.1 403 Forbidden

{
    code: 403,
    success: false,
    message: "Forbidden."

}
我们应该使用RFC HTTP状态码,还是可以使用我们自己的自定义代码?哪里是最好的、正确的方法?

最短的方法 你完全正确

长话短说 在restful API设计中,您必须使用中指定的官方HTTP代码。请不要为每个请求发送200 OK。200 OK是为实际成功的请求保留的,并且服务器使用特定资源的有效状态进行响应。大多数用例都有代码。如果您仍然需要区分相同类型的错误,例如
禁止
,您可以发送自定义错误代码。但是HTTP响应仍然是一个错误,因此不应使用200 OK

关于建议的错误方案,您不应在正文中发送代码和状态。这已作为HTTP状态发送,因此是冗余的。此外,布尔成功标志是多余的,因为HTTP代码类型已经指出它是否成功(2xx=>success,4xx客户端错误,5xx服务器错误)。 正文应该包含额外的上下文,这将帮助API客户机解决问题

设计良好的API错误响应应包含有助于解决可能问题的信息:

  • 服务器上每个请求生成的请求ID
  • 详细错误消息
  • (可选)内部错误代码
  • (可选)错误类别
  • (可选)参考api文档/错误描述
示例

HTTP/1.1 403 Forbidden
{ 
    "requestId": "a5e5dd13-0047-4d2e-b96c-55a5031f0511", 
    "message": "You are not allowed to access this resource. Missing write permission.",
    "category": "AccessControl"
}
如果这仍然不足以让您的团队领导相信,您可以指出一些设计良好的REST API: