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

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

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

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

或者在错误情况下：

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

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

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

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

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

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

• 要么有两个争吵的社区，每个社区都有他们最喜欢的方法（始终使用 HTTP 状态与从不使用 HTTP 状态）
• 或者我遗漏了重要的一点，您会告诉我，虽然在某些情况下应该使用 HTTP 状态，但在某些特定情况下，HTTP 状态不适合，并且“状态”JSON 属性会发挥作用。

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

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