为什么JSON应该有状态属性

Question

我无意中发现了一种非常普遍的做法。我甚至发现了一个网页，给它起了个名字，但我忘了名字，在谷歌上再也找不到那个网页了。

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

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

或在错误情况下：

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

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

REST使用客户端和服务器之间的HTTP通信方式，例如，删除应该使用“DELETE”动词。同理，一个资源找不到就应该用404等等。因此，按照这种思路，任何错误情况都应该在HTTP状态中正确编码。

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

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

我主要想从你那里得到两个可能的答案：

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

Answer 1

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

一句话：通过JSON做这件事更可靠。

Answer 2

您将在此处混合两个不同的层：

>

当使用JSON交换数据时，您当然可以省略status属性，但是如果您只读取一个属性就知道JSON是否包含您请求的对象或错误消息，那么解析JSON就更容易了。

因此，是的，返回一个200状态代码并在JSON中有一个“status”：“error”属性是完全正常的。

Answer 3

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

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