Question

我想知道当服务器端出现错误并且响应正文内部出现错误时返回HTTP 200 OK是否正确。

示例：

我们正在发送http GET
服务器端出现意外情况。
服务器返回http 200 OK状态代码，并在响应中显示错误（例如{"status":"some error occured"}

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

Answer 1

不，这是非常不正确的。

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

如果在处理GET时出现问题，正确的状态代码是4xx（＆＃34;你搞砸了＃34;）或5xx（＆＃34;我搞砸了＃34;）。

Answer 2

HTTP状态代码说明了HTTP协议。 HTTP 200表示HTTP级别的传输正常（即请求在技术上是正常的，服务器能够正确响应）。请参阅this wiki page以获取所有代码及其含义的列表。

HTTP 200与您的＆＃34;业务代码＆＃34;的成功或失败无关。在您的示例中，HTTP 200是可接受的状态，表示您的业务代码错误消息＆＃34;已成功转移，前提是没有技术问题阻止业务逻辑正常运行。

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

总结：是的，在http响应中发送错误消息（非技术问题）以及HTTP状态200是有效的。这是否适用于您的情况取决于您。例如，如果客户端要求的文件不在那里，则更像是404。如果服务器上的配置错误可能是500。如果客户要求预订满座的飞机上的座位，那将是200和您的＆＃34;实施＆＃34;将指示如何识别/处理此问题（例如，带有{ "booking","failed" }的JSON块）

Answer 3

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

因此，HTTP 200将有助于解决业务逻辑错误。但是HTTP错误代码所涵盖的所有错误都应该使用它们。

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

Answer 4

为明确起见，您应该在符合协议的地方使用HTTP错误代码，而不要使用HTTP状态代码来发送业务逻辑错误。

余额不足（em），没有出租车可用，用户名/密码错误之类的错误符合HTTP状态200，并带有特定于应用程序的错误在响应主体中进行处理。

请参见this software engineering answer：

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

Answer 5

如果我们考虑现实生活，我认为这类问题可以解决。

不良做法：

示例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 6

HTTP是用于处理Internet上数据传输的协议。

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

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

HTTP不能说“好吧，这个答案是gobbledigook，但是这里是”。它只是说200 OK。

即：我已经完成了将它交给您的工作，其余的取决于您。

我知道这个问题已经回答了，但是我用我能理解的词来表达。抱歉，重复了。

Answer 7

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

您的API和您的回复必须清晰易懂。它应符合某种规范，并且该规范应定义什么是有效响应。符合有效响应的内容应产生200码。某些不符合有效响应的内容应产生4xx或5xx代码，以指示为什么无法生成有效响应。

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

我想比方说调用函数parseFoo。致电parseFoo("invalid data")会怎样？它是否返回错误结果（可能为null）？还是抛出异常？对于一种方法或另一种方法是否正确，许多人会采取近乎宗教的立场，但最终这取决于API规范。

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

关于“成功返回错误”是构成HTTP成功还是错误，显然存在意见分歧。我看到不同的人以不同的方式解释相同的规范。因此，当然要选择一方，但也要接受，无论哪种方式，整个世界都不会同意您的看法。我？我发现自己在中间的某个地方，但我会提供一些常识性的考虑。

如果您的服务器端代码在调度请求时捕获到意外的异常，这听起来像是500 Internal Server Error的定义。 这似乎是OP的情况。应用程序不应为意外错误返回200 ，但也请参见第3点。
如果您的服务器端代码应能够正常处理给定的无效输入，并且不构成“例外”错误条件，则您的规范应容纳可提供有意义的HTTP 200响应诊断信息。
最重要的是：有一个规格。使其一致。坚持下去。

在OP的情况下，听起来好像您有一个事实上的标准，未处理的异常会产生200，并带有可区分的响应主体。这不是理想的选择，但是如果没有解决问题并积极引起问题，则可能有更大，更重要的问题需要解决。

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

7 个答案: