在Restful错误响应中，是否应该使用HTTP状态？

Question

我正在编写一个Restful API，需要返回错误信息，但我不确定该选择哪个路由。

路由1 - HTTP状态 当客户端发送错误数据时，使用HTTP错误状态码。 例如：401 - 未经授权，410 - 模型不存在，412 - 模型验证错误等

路由2 - JSON成功或错误失败 API返回json，我考虑使用http头200返回所有内容，然后在我的JSON中处理错误和成功。 例如： {"status" : "error", "message" : "Model validation error", "data" : ["user name required", "user email required"]}

我应该选择哪个路由？为什么？优缺点是什么？

- Devin Dixon

Answer 1

我正在编写一个 Restful API，并且需要返回错误信息，但不确定应该选择哪种方式。

方案1 - HTTP 状态码

当客户端发送错误数据时，使用 HTTP 错误状态码。

在任何声称是 RESTful 的 Web 服务实现中都必须使用 HTTP 状态码。规范的核心原则是利用和扩展 Web，以完全支持传输表现状态。为了与现有的 Web 基础设施进行交互，REST 实现应通过适当的 HTTP 状态码指示请求的状态。例如：

200 - 正常
201 - 已创建内容
401 - 未授权
403 - 禁止访问
500 - 服务器错误
501 - 未实现

对于许多这些状态的响应，在 HTTP 规范允许的情况下，也可以在响应正文中包含实体表示形式。对于“正常”的非错误响应，此表示形式通常将是由 HTTP 请求“操作”的实体。对于错误响应，如果包括表示形式，则应提供有关发生的错误的更多信息。这就是我们转到你的第二个选项的地方。

方案2 - JSON 成功或错误失败

API 返回 JSON，考虑使用 HTTP 头200返回所有内容，但在我的 JSON 中处理错误和成功。

绝不能对所有响应都返回200 OK。许多已经实现良好的 HTTP 客户端需要响应中的状态码来确定是否成功。始终以200 OK响应可能会导致第三方客户端库错误地处理传入数据，并且还要求您的客户端解析响应正文以确定是否实际发生了错误。

尽管如此，添加有关发生的错误的其他信息可能非常有帮助，因此一定要考虑将其添加到响应正文中。你提出的格式看起来很好，但老实说，假设你适当地使用 HTTP 状态码，则 status 元素是多余的。更像：

{
    "message": "Model validation error",
    "data": [
        "user name required",
        "user email required"
    ]
}

- Perception