7

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

路由 1 - HTTP 状态

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

例如：401 - 未授权，410 - 模型不存在，412 - 模型验证错误等

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

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

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

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

4

1 回答 1

13

我正在编写一个 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"
    ]
}
于 2013-03-09T13:39:15.857 回答