6

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

实践是来自 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 属性会发挥作用。
4

3 回答 3

4

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

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

于 2012-07-11T13:09:03.967 回答
3

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

  • HTTP 用于建立（高级）连接和传输数据。因此，HTTP 状态代码会通知您连接是否建立以及如何建立，或者为什么没有建立。在成功的连接上，HTTP 请求的主体可以包含任何内容（例如 XML、JSON 等），因此这些状态代码必须定义一般含义。它不会通知您响应的正确性或类型（例如错误消息或数据）。

  • 当使用 JSON 交换数据时，您当然可以省略该status属性，但是如果您知道它是否包含您正在请求的对象或仅通过读取一个属性的错误消息，则解析 JSON 会更容易。

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

于 2012-07-11T13:34:22.473 回答
2

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

底线：通过 JSON 执行此操作更可靠。

于 2012-07-11T13:13:20.667 回答