在响应正文中返回http 200 OK并出错

Question

我想知道HTTP 200 OK在服务器端发生错误并且响应正文内部出现一些错误时返回是否正确.

例:

1. 我们正在发送 http GET
2. 服务器端出现意外情况.
3. 服务器http 200 OK在响应中返回错误状态代码(例如,{"status":"some error occured"}

是不是正确的行为？我们不应该改变状态代码吗？

Answer 1

不,这是非常不正确的.

HTTP是一种应用程序协议.200意味着响应包含表示所请求资源的状态的有效载荷.错误消息通常不是该资源的表示.

如果在处理GET时出现问题,则正确的状态代码为4xx("你搞砸了")或5xx("我搞砸了").

Answer 2

HTTP状态代码说明了HTTP协议.HTTP 200表示HTTP级别的传输正常(即请求技术上正常,服务器能够正确响应).请参阅此Wiki页面以获取所有代码及其含义的列表.

HTTP 200与"业务代码"的成功或失败无关.在您的示例HTTP 200中,可接受的状态表示您的"业务代码错误消息"已成功传输,前提是没有任何技术问题阻止业务逻辑正常运行.

或者,HTTP 5xx如果服务器上发生技术或不可恢复的问题,您可以让服务器响应.或者HTTP 4xx如果传入的请求有问题(例如错误的参数,意外的HTTP方法......)同样,这些都表示技术错误,而HTTP 200表示没有技术错误,但不保证业务逻辑错误.

总结:是的,在http响应中发送错误消息(非技术问题)以及HTTP状态200是有效的.这是否适用于您的情况取决于您.例如,如果客户端要求的文件不存在,则更像是a 404.如果服务器上的配置错误可能是500.如果客户要求在预订满的飞机上的座位,那将是200你的"实施"将决定如何识别/处理这个(例如带有a的JSON块{ "booking","failed" })

Answer 3

即使我想将业务逻辑错误作为HTTP代码返回,也没有针对该错误的可接受的HTTP错误代码而不是使用HTTP 200,因为它将歪曲实际错误.

因此,HTTP 200将有利于业务逻辑错误.但是HTTP错误代码所涵盖的所有错误都应该使用它们.

基本上HTTP 200意味着服务器正确处理用户请求(如果飞机上没有座位,则无论因为用户请求是否正确处理,它甚至可以返回飞机上可用的多个座位,因此会有根本没有业务逻辑错误或者业务逻辑可以在客户端.业务逻辑错误是一个抽象的含义,但HTTP错误更明确).

Answer 4

澄清一下，您应该在适合协议的地方使用 HTTP 错误代码，而不是使用 HTTP 状态代码来发送业务逻辑错误。

诸如余额不足、没有可用出租车、错误的用户/密码等200错误符合 HTTP 状态，并在响应正文中处理特定于应用程序的错误。

请参阅此软件工程答案：

我会说最好明确协议的分离。让HTTP服务器和Web浏览器做好自己的事情，并让应用程序做它自己的事情。应用程序需要能够发出请求，它需要响应——以及它关于如何请求、如何解释响应的逻辑可能比 HTTP 透视图更（或更少）复杂。

Answer 5

我认为人们过于重视应用程序逻辑而不是协议问题。重要的是响应应该有意义。如果您有一个提供动态资源的 API，并且对 X 发出了请求，而 X 是从带有数据 Z 的模板 Y 派生的，并且 Y 或 Z 当前不可用，该怎么办？这是业务逻辑错误还是技术错误？正确答案是：“谁在乎呢？”

您的 API 和您的响应必须易于理解且一致。它应该符合某种规范，并且该规范应该定义什么是有效响应。符合有效响应的内容应生成 200 代码。不符合有效响应的内容应生成 4xx 或 5xx 代码，指示无法生成有效响应的原因。

如果您的规范对有效响应的定义允许{ "error": "invalid ID" }，那么它就是成功的响应。如果您的规范没有做到这一点，那么用 200 代码返回该响应将是一个糟糕的决定。

我将与调用函数进行类比parseFoo。当你打电话时会发生什么parseFoo("invalid data")？它是否返回错误结果（可能为 null）？或者它会抛出异常吗？对于一种方法或另一种方法是否正确，许多人会采取近乎宗教的立场，但最终取决于 API 规范。

“状态代码元素是一个三位数整数代码，给出尝试理解和满足请求的结果”

显然，对于“成功返回错误”是否构成HTTP成功或错误存在不同的意见。我看到不同的人以不同的方式解释相同的规格。所以，当然要选择一边，但也要接受这样的事实：无论哪种方式，整个世界都不会同意你的观点。我？我发现自己处于中间位置，但我会提供一些常识性的考虑。

1. 如果您的服务器端代码在分派请求时捕获意外异常，这听起来就像500 Internal Server Error. 这似乎是OP的情况。应用程序不应200因意外错误而返回 a，但另请参阅第 3 点。
2. 如果您的服务器端代码应该能够正常处理给定的无效输入，并且它不构成“异常”错误条件，那么您的规范应该容纳提供有意义的诊断信息的 HTTP 200 响应。
3. 最重要的是：有一个规格。使其保持一致。坚持下去。

在OP的情况下，听起来你有一个事实上的标准，未处理的异常会产生一个带有可区分响应主体的200。这并不理想，但如果它没有破坏事物并主动引发问题，那么您可能有更大、更重要的问题需要解决。

Answer 6

我认为如果我们考虑一下现实生活，这些问题就会迎刃而解。

不良做法：

示例 1：

Darling everything is FINE/OK (HTTP CODE 200) - (Success):
{
  ...but I don't want us to be together anymore!!!... (Error)
  // Then everything isn't OK???
}

示例 2：

You are the best employee (HTTP CODE 200) - (Success):
{
  ...But we cannot continue your contract!!!... (Error)
  // Then everything isn't OK???
}

良好做法：

 Darling I don't feel good (HTTP CODE 400) - (Error):
{
  ...I no longer feel anything for you, I think the best thing is to separate... (Error)
  // In this case, you are alerting me from the beginning that something is wrong ...
}

这只是我个人的意见，每个人都可以按照自己最舒服或最需要的方式实施。

注意：这个解释的想法来自一个好朋友@diosney

Answer 7

HTTP 是处理通过互联网传输数据的协议。

如果传输由于某种原因中断，HTTP 错误代码会告诉您为什么无法将其发送给您。

正在传输的数据不由 HTTP 错误代码处理。只是传输方法。

HTTP 不能说“好吧，这个答案是官样文章，但就是这样”。它只是说200 OK。

即：我已经完成了把它交给你的工作，剩下的就看你了。

我知道这个问题已经得到了回答，但我用我能理解的语言表达了它。抱歉有任何重复。