问HTTP状态代码4xx vs 5xx

EN

坚持标准！

您将发送给客户端的HTTP状态代码的决定取决于您，但您确实应该坚持这些标准。RFC 7231是HTTP1.1协议的内容和语义的当前引用。在HTTP协议之上创建API时，必须读取它。

4xx与5xx状态码

对客户端错误使用4xx状态代码，对服务器错误使用5xx状态代码：

6.5。客户端错误4xx 状态代码的4xx (客户端错误)类表示客户端似乎出错了。除了响应HEAD请求时，服务器应该发送一个包含错误情况解释的表示，以及它是临时的还是永久的。这些状态代码适用于任何请求方法。用户代理应该向用户显示任何包含的表示形式。6.6。服务器错误5xx 状态代码的5xx (Server Error)类表示服务器知道它已经错误或无法执行请求的方法。除了响应HEAD请求时，服务器应该发送一个包含错误情况解释的表示，以及它是临时的还是永久的。用户代理应该向用户显示任何包含的表示形式。这些响应代码适用于任何请求方法。

应该使用哪种状态代码？

对于您在问题中提到的情况，您可以使用400或422 (来自WebDAV，一个HTTP扩展)：

6.5.1.400个错误请求 400 (坏请求)状态代码指示服务器不能或不会处理请求，原因是一些被认为是客户端错误(例如，格式错误的请求语法、无效的请求消息帧或虚假的请求路由)。11.2。422个不可处理实体 422 (非处理实体)状态代码意味着服务器理解请求实体的内容类型(因此415(不支持的媒体类型)状态代码是不合适的)，请求实体的语法是正确的(因此400 (坏请求)状态代码是不合适的)，但是无法处理包含的指令。例如，如果XML请求体包含格式良好(即语法正确)但语义错误的XML指令，则可能出现此错误情况。

与状态代码一起，确保发送一个表示形式(如JSON或XML)，其中包含对响应有效负载中错误情况的解释。看看RFC 7807，它描述了HTTP问题详细信息的标准。

一个伟大的决策图表

有关更多细节，请查看来自拉克斯堡的这个决策图：

​

状态代码分为三大类：

​

​

​

从这里开始：

​

​

​

选择2xx和3xx状态代码：

​

​

​

选择4xx状态代码：

​

​

​

选择5xx状态代码：

​

​

这完全取决于你想要向客户发送什么样的响应。

但是，在发送回复时，您必须意识到，对于导致请求失败的事件，它应该是通用的和清晰的。

设计API就像设计客户机和服务器之间的协议一样。服务器必须服务于客户端，直到该协议或API规范得到遵守为止。它应该在Api规范文档中清楚地注明。

在上述情况下，由于服务器正在接受请求param的某些值，而且客户端没有发送请求，这是客户端的错误，因为客户端不同意在发送请求之前提供的api规范。

在这种情况下，服务器应该返回HttpResponseStatus.BAD_REQUEST，它在代码中等于400。

提示：--我建议您不仅返回错误代码，而且在发生错误时提供一些错误消息和响应。

e.g

response : { errorCode:4xx, errorMessage:"Some thing went wrong"}

坚持标准！博士，但在某些情况下，它可以放松下来。

我认为4xxvs5xx取决于与客户端的服务器关系。如果您正在构建一个公共API，或者您不确定如何使用该API，我同意接受的答案。事实上，我认为在构建API时，这应该是一个默认的选择。

然而，区分4xx和5xx (具体而言是400和500 )有一定的成本。在某些情况下，成本可能是不合理的。假设您正在构建一个API，并且对客户端有完全的控制。API和客户端都属于同一个应用程序，它们都将一起发布(用DDD术语表示的有界上下文)。客户机和API本质上是一个单独的应用程序，使用HTTP作为粘合剂。基本上，我们没有使用API来与客户端分离。在构建类似于前端后端的东西时，这种情况经常发生。就分层而言，您可能有以下几个方面：

• 预先(了解业务规则)
• API/BFF(?)
• 域模型或下游服务(强制执行业务规则)

现在，在此场景中构建API时，您可能想要走捷径，只需在下游以最小的转换传递前端请求。基本上保持API层的薄薄的。无论如何，该模型将强制执行业务规则(例如，抛出一个异常)。这些类型的崩溃会由web框架自动转换为500错误。最终的结果是，您可能不会向客户端返回“适当的”400或412状态代码，而是返回500，从HTTP的角度来看，这是不正确的。但你猜怎么着。你的客户不关心，也不区分400和500 -它对待他们一样。两者都被认为是“应用程序”中的bug。在客户端可能会有对503的特殊待遇，但我认为这是另一种考虑。

// internal api with a tightly coupled consumer (think SPA)

public Response BuyLifeInsurance(Request request) {

    // how much upstream and downstream logic do you want to
    // duplicate here knowing that _downstream still enforces
    // all the rules and will throw on violation? And client
    // also knows about the rules and the violation means a bug.
    // Why think about 400 vs 412 semantics? Who cares if it
    // is 400 or 500 if both are treated as bugs that should be
    // fixed by _your_ team (either on client or server)? You 
    // should care about life insurance and not http purity anyway :)

    // why not let the call below crash and return 500 and figure
    // out where the bug is based on logs?

    _downstream.BuyLifeInurance(
        new Age(request.age),       
        new Amount(request.amount));
}

基本上，在某些情况下，重复已经在客户端上实现并在下游模型中执行的业务逻辑可能是浪费的。因此，API层还是以牺牲理论纯洁性为代价而保持较薄。我将此场景称为弱API™。一个有用的实验--如果不是HTTP，你会把多大的精力放在遵守协议习惯上？如果这不是一个API而是一个简单的内部库呢？IMHO只有在您使用API将其与客户端分离(这是大多数情况下的情况，但也有我前面概述的例外情况)时才能支付费用。