为什么 JSON 应该有一个 status 属性答案

【问题标题】：Why should JSON have a status property为什么 JSON 应该有一个 status 属性
【发布时间】：2012-07-11 02:34:35
【问题描述】：

我偶然发现了一种非常普遍的做法。我什至找到了一个为其命名的网页，但我忘记了名称，并且无法再在 google 上找到该页面。

实践是来自 REST 服务的每个 JSON 响应都应具有以下结构：

{
    "status": "ok",
    "data": { ... }
}

或在错误情况下：

{
    "status": "error",
    "message": "Something went wrong"
}

我的问题：JSON 中为什么需要这样的“状态”属性有什么意义？在我看来，这就是 HTTP 状态代码的用途。

REST 在客户端和服务器之间使用 HTTP 通信方式，例如“DELETE”动词应该用于删除。同样，如果找不到资源等，则应使用 404。因此，根据这种想法，任何错误情况都应在 HTTP 状态中正确编码。

是否有特定原因在错误情况下返回 HTTP 200 状态代码并在 JSON 中出现错误？在处理响应时，它似乎使 javascript 条件分支更加复杂。

我发现在某些情况下，状态可能是“重定向”以告诉应用程序重定向到某个 URL。但如果使用了正确的 HTTP 状态码，浏览器将“免费”执行重定向，从而正确维护浏览历史记录。

我主要想象你的两个可能的答案：

【问题讨论】：

标签： json rest

【解决方案1】：

您在这里混合了两个不同的层：

HTTP 用于建立（高级）连接和传输数据。 HTTP status codes 因此会通知您是否以及如何建立连接或为什么没有建立连接。在成功的连接上，HTTP 请求的主体可以包含任何内容（例如 XML、JSON 等），因此这些状态代码必须定义一般含义。它不会通知您响应的正确性或类型（例如错误消息或数据）。
当使用 JSON 交换数据时，您当然可以省略 status 属性，但是如果您知道它是否包含您请求的对象或错误消息，则解析 JSON 会更容易读取一个属性。

所以，是的，返回 200 状态代码并在 JSON 中具有 "status": "error" 属性是完全正常的。

【讨论】：

+1 - 确切地说，这种 JSON 模式允许您报告 应用程序级别 错误。 HTTP 并非旨在报告这一层的错误。
这个答案比我的好 20 倍。
Justin - 在 REST 中，HTTP 旨在用于报告应用程序级别的错误。
Brian - 不，REST 只是一种样式，并不绑定到 HTTP（请参阅 "REST does not restrict communication to a particular protocol"）。仅仅因为许多服务使用 HTTP 状态代码来报告应用程序级别的错误，你不能说它是“注定要这样”的。
感谢您的澄清。我现在明白你的意思了。从 HTML 文档的角度来看，我会争辩说，不，TCP 是传输，HTTP 是业务。 HTTP 404 表示未找到文档； HTTP 201 表示已创建文档等。这也是 REST 建议在适用的情况下使用的内容。但我意识到可能存在与业务相关的错误，例如“您无法将这张票的状态从进行中更改为已解决，因为根据工作流程，您需要首先满足这个和那个先决条件”，这绝对不会映射到任何 HTTP 状态代码...

【解决方案2】：

HTTP 状态码可能由很多因素引起，包括负载平衡器、代理、缓存、防火墙等。这些都不会修改您的 JSON 输出，除非它们完全破坏它，这也可以视为一个错误。

底线：通过 JSON 更可靠。

【讨论】：

这是否会归结为应用程序返回一个 4xy HTTP 状态代码加上一个 JSON 正文，如果出现业务错误，则带有解释？在错误情况下返回 200 对我来说只是感觉不对，如果处理不当可能会产生不良的副作用。
是的，我推荐两者都用。

【解决方案3】：

你是对的。我认为您所看到的是人们没有正确执行 REST 的副作用。或者根本不做 REST。使用 REST 不是设计良好的应用程序的先决条件；没有规定 webapps 必须是 REST-ful。

另一方面，对于错误情况，有时应用程序想要返回 200 代码但错误表示业务逻辑失败。 HTTP 错误代码并不总是与应用程序业务错误的语义相匹配。

【讨论】：