我偶然发现了一种我发现非常普遍的做法。我甚至找到了一个给这个名字起来的网页，但我忘了这个名字，而且我再也找不到谷歌那个页面了。
实践是来自REST服务的每个JSON响应都应具有以下结构：
{
"status": "ok",
"data": { ... }
}
或在错误情况下：
{
"status": "error",
"message": "Something went wrong"
}
我的问题：为什么在JSON中需要这样的“状态”属性是什么意思？在我看来，这是为HTTP状态代码制作的。
REST使用客户端和服务器之间的HTTP通信方式，例如，应使用“DELETE”动词进行删除。同样，如果找不到资源等，则应该使用404等。因此，在思考的情况下，任何错误情况都应该在HTTP状态下正确编码。
是否有特定原因在错误情况下返回HTTP 200状态代码并在JSON中出现错误？它似乎只是在处理响应时使javascript条件分支更复杂。
我发现了一些状态可以“重定向”以告诉应用程序重定向到某个URL的情况。但如果使用了正确的HTTP状态代码，浏览器将“免费”执行重定向，从而正确维护浏览历史记录。
我主要想出两个可能的答案：
答案 0 :(得分：4)
你是对的。我认为你所看到的是人们没有正确地做REST的副作用。或者根本就不做REST。使用REST不是精心设计的应用程序的先决条件;没有规定Webapps必须是REST-ful。
另一方面，对于错误情况，有时应用程序想要返回200代码但是错误表示业务逻辑失败。 HTTP错误代码并不总是与应用程序业务错误的语义相匹配。
答案 1 :(得分：3)
您在这里混合了两个不同的图层：
HTTP用于建立（高级）连接和传输数据。 HTTP status codes因此告知您是否以及如何建立连接或为何不建立连接。在成功连接时，HTTP请求的主体可以包含任何内容（例如XML，JSON等），因此这些状态代码必须定义一般含义。它不会通知您有关响应的正确性或类型（例如错误消息或数据）。
使用JSON进行数据交换时，您当然可以省略status属性，但是如果您知道它是否包含您请求的对象或错误消息，则更容易解析JSON只读一个属性。
所以，是的，返回200状态代码并在您的JSON中拥有"status": "error"属性是完全正常的。
答案 2 :(得分：2)
HTTP状态代码可能由很多东西引起，包括负载均衡器，代理，缓存，防火墙等。这些都不会修改你的JSON输出，除非它们完全破坏它，它也可以被视为错误。
底线：通过JSON实现它更可靠。