我是否应该使用HTTP状态代码来描述应用程序级别的事件

我处理过的几台服务器将返回HTTP 200，以请求客户端应认为失败的请求，其中的内容为“ success：false”。

在我看来，这似乎不是HTTP代码的正确实现，尤其是在身份验证失败的情况下。我已经很简洁地阅读了HTTP错误代码，其中“ 4xx”指示在更改之前不应该再次发出请求，而“ 5xx”指示该请求可能有效或无效，可以重试，但未成功。在这种情况下，200：登录失败，或200：找不到该文件，或200：缺少参数x，这肯定是错误的。

另一方面，我可以看到有人争论说“ 4xx”应仅表示请求的结构性问题。因此，这很适合返回200：错误的用户名/密码，而不是未经授权的401，因为允许客户端进行请求，但是恰好是错误的。这个论点可以概括为：如果服务器能够处理请求并做出确定，则响应代码应为200，并且由客户端检查主体以获取更多信息。

基本上，这似乎是一个优先事项。但这并不令人满意，因此，我想知道，如果有人有理由说明这些范例中的任何一个更为正确。

有趣的问题。

基本上，我们可以将其简化为按照类似于OSI层的术语对事物进行分类的正确方法。HTTP通常定义为应用程序级别协议，而HTTP实际上是通用的客户端/服务器协议。

但是，实际上，服务器几乎总是中继设备，客户端是Web浏览器，负责解释和呈现内容：服务器只是将内容传递给任意应用程序，而应用程序会发回任意脚本，浏览器负责执行。HTTP交互本身（请求/响应形式，状态代码等）主要是如何有效地请求，提供服务和呈现任意内容，而不会造成干扰。实际上，许多状态代码和标头都是为此目的而设计的。

尝试搭载HTTP协议来处理特定于应用程序的流的问题在于，您剩下两个选择之一：1）您必须使请求/响应逻辑成为HTTP规则的子集；或2）您必须重用某些规则，然后关注点分离趋于变得模糊。起初看起来很干净，但是我认为这是您随着项目的发展而后悔的那些设计决策之一。

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

值得一提的是，这种方法的另一个好处是，应用程序通常应该不依赖于底层的传输协议（从逻辑的角度来看）。HTTP本身在过去已经发生了变化，现在在SPDY之后，我们有了HTTP 2。如果您仅将您的应用视为HTTP功能插件，那么当新的基础架构接管时，您可能会陷入困境。

这个问题是基于观点的，但是无论如何。

我的看法是200可以解决“软错误”。当涉及到构建API时，我尝试区分这些错误和“硬错误”。

“软错误”的状态码为200，但包含错误说明和成功状态false。仅当结果“符合预期”时才会发生“软错误”，但从严格意义上讲不会成功。

重要的是要注意，“软错误”更多地是对实现者的提示。因此，重要的是还提供有关错误的更多信息，例如人类可读的错误消息和/或可用于向最终用户提供反馈的某种代码。这些错误为实现者（和最终用户）提供了有关服务器端发生的情况的更多信息。

例如，假设您有一个具有搜索功能的API，但是在搜索过程中不会产生任何结果。这不是错误的，但也不是“成功”，并不是严格意义上的定义。

格式化为JSON的示例：

{
    "meta" {
        "success": false,
        "message": "Search yielded no results",
        "code": "NORESULTS"
    }
    "data": []
}

另一方面，“硬错误”将带有建议用于该错误的状态代码。用户未登录？– 403 /401。输入格式错误？– 400.服务器错误？– 50倍。等等。

同样，它有点基于意见。某些人想平等对待所有错误，“硬错误”处理所有错误。没有搜索结果？那是404！在硬币的另一侧，没有搜索结果？–这是预期的，没有错误。

例如，要考虑的另一个重要因素是您的体系结构。如果您使用JavaScript XHR请求和jQuery或AngularJS与API进行交互。这些“硬错误”必须通过单独的回调进行处理，而“软错误”可以通过“成功”回调进行处理。没有破坏任何东西，结果仍然是“按预期”。客户端代码然后可以查看成功状态和代码（或消息）。并将其打印给最终用户。

API有两个方面：实施API的努力，以及所有客户端正确使用API​​的努力。

作为客户端的作者，我知道当我向Web服务器发送请求时，我可能会收到错误（从未正确地与服务器交谈）或收到带有状态码的回复。我必须处理错误。我必须处理好回应。我必须处理预期的，有据可查的“不良”回复。我必须处理其他任何回来的事情。

在设计API时，您应该查看客户端最容易处理的内容。如果客户端发送格式正确的请求，并且您可以执行请求所要求的操作，那么您应该给出200范围内的答案（在某些情况下，该范围内200以外的数字是适当的）。

如果客户询问“给我所有类似...的记录”，并且为零，那么成功的200和零记录的数组是完全合适的。您提到的情况：

“登录失败”通常应为401。“找不到文件”应为404。“缺少参数x”应为500左右（实际上，如果服务器确定请求是错误的，则为400； 500）如果服务器完全被我的请求弄糊涂了，不知道发生了什么）。在这种情况下，返回200是没有意义的。这仅意味着作为客户的作者，我不能只看状态码，还必须研究答复。我不能只说“状态200，太好了，这是数据”。

特别是“参数缺失”-这是我永远不会处理的。这表示我的要求不正确。如果我的请求不正确，我将没有备用来解决该错误的请求-我会发送正确的请求开始。现在，我不得不处理它。我得到200，必须检查是否有“参数缺失”的答复。那是糟糕的。

最后，有一打或两个状态码可以处理许多不同的情况，您应该使用它们。