HTTP状态应该用于Restful错误响应吗？

Question

我正在写一个Restful API，我必须返回错误信息，但我不确定要走哪条路。

路线1 - HTTP状态

客户端发送错误数据时使用HTTP错误状态

Ex：401 - 未授权，410 - 模型不存在，412 - 模型Validaiton错误等

路由2 - JSON成功或错误失败

API返回json，我正在考虑使用http标头200返回所有内容，但随后在我的JSON句柄中出现错误并成功

例： {“status”：“错误”，“消息”：“模型验证错误”，“数据”：[“需要用户名”，“需要用户电子邮件”]}

我应该走哪条路？为什么？优点和缺点。

Answer 1

  

我正在写一个Restful API，我必须返回错误消息，但我是   不知道要走哪条路。

     

路线1 - HTTP状态

     

客户端发送错误数据时使用HTTP错误状态

HTTP状态代码 绝对 应在声称为RESTful的任何Web服务实现中使用。规范的核心原则是利用和扩展Web以完全支持代表性状态的转移。为了与现有Web基础结构进行互操作，REST实现应通过适当的HTTP状态代码指示请求的状态。例如：

200 - 好的 201 - 内容创建
401 - 未经授权的 403 - 禁止
500 - 服务器错误
501 - 未实施

当响应许多这些状态时，HTTP规范也允许它在响应主体中包含实体表示。在“正常”，非错误响应的情况下，该表示通常是由HTTP请求“操作”的实体。在错误响应的情况下，表示（如果包括）应提供有关发生的错误的更多信息。这是我们选择2的选择。

  

路由2 - JSON成功或错误失败

     

API返回json，我正在考虑返回所有内容   http标头200，但随后在我的JSON句柄错误和成功

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

话虽如此，添加有关发生的错误的其他信息可能非常有用，所以一定要考虑将其添加到响应正文中。您建议的格式看起来很好，但老实说status元素是多余的，假设您正确使用HTTP状态代码。更像是：

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