如果请求缺少必需的参数，我应该使用什么HTTP状态响应代码?

小开

你可以发送一个400坏请求代码。它是一种更通用的4xx状态码，因此您可以使用它来表示您的意图:客户端正在发送一个请求，该请求缺少应用程序正确处理它所需的信息/参数。

小开

我不确定是否有一个固定的标准，但我会使用400错误请求，这是最新的HTTP规范(从2014年开始)文件如下:

6.5.1. 400错误请求

400(坏请求)状态码表示服务器不能或将不会处理请求由于某些东西被认为是客户端错误(例如，格式错误的请求语法，无效的请求
.消息帧或欺骗性请求路由)

小开

. net中的WCF API在使用完全时，通过返回一个HTTP 404 "Endpoint Not Found"错误来处理缺少的参数。

如果考虑web服务方法名及其参数签名，404 Not Found是有意义的。也就是说，如果你公开了一个web服务方法LoginUser(string, string)，并且请求了LoginUser(string)，后者是找不到的。

基本上，这意味着无法找到您正在调用的web服务方法以及您指定的参数签名。

10.4.5 404未找到

服务器没有找到任何与请求uri匹配的内容。没有说明这种情况是暂时的还是永久性的。< / p >

400 Bad Request，作为哥特建议，仍然是一个有效的响应代码，但我认为它通常用于指示较低级别的问题。它很容易被解释为一个格式错误的HTTP请求，可能缺少或无效的HTTP头，或类似的情况。

10.4.1 400个错误请求

由于格式错误，服务器无法理解请求语法。客户端不应该重复请求修改。< / p >

小开

可以认为应该使用404 Not Found，因为无法找到指定的资源。

小开

我经常使用403 Forbidden错误。理由是请求被理解了，但我不会按照要求去做(因为事情是错误的)。响应实体解释了错误所在，因此如果响应是HTML页面，错误消息就会出现在页面中。如果是JSON或XML响应，错误信息就在里面。

10.4.4禁止403

服务器理解请求，但拒绝完成它。
授权没有帮助，请求不应该重复。
如果请求方法不是HEAD，服务器希望使用
公开为什么要求没有得到满足，它应该描述实体拒绝的原因。如果服务器不希望这样做使此信息对客户机可用，即状态代码404

.
.
.

小开

最佳答案

基于规范，状态422似乎最合适。

422(不可处理实体)状态码表示服务器理解请求实体的内容类型(因此是 415(不支持的媒体类型)状态码不合适) 请求实体的语法是正确的(因此是400(坏请求) 状态码不合适)，但无法处理包含的指令。例如，如果XML 请求主体包含格式良好的(即语法正确)，但是语义错误，XML指令

他们指出，格式错误的xml是错误语法的一个例子(需要400)。格式错误的查询字符串似乎与此类似，因此400似乎不适合缺少参数的格式良好的查询字符串。

注意:由于上面的RFC是关于WebDAV的，所以可能会有这样的误解，即422和其他一些RFC只能在WebDAV的上下文中使用，而在WebDAV之外使用它们是“非标准”的。但这只意味着这些状态码是在此RFC的上下文中引入的。事实上，这些定义的措辞都是经过精心选择的，不是专门针对WebDAV的。

小开

对于那些感兴趣的人，Spring MVC(3。至少X)在这种情况下返回400，这对我来说似乎是错误的。

我测试了几个谷歌url (accounts.google.com)，并删除了所需的参数，在这种情况下，它们通常返回404。

我会复制谷歌。

小开

我通常去422(不可处理的实体)，如果所需的参数中的某些东西不匹配API端点所需的(如太短的密码)，但对于缺少的参数，我会去406(不可接受)。

小开

在我们的一个API项目中，我们决定将409状态设置为一些请求，当我们因为缺少参数而不能完全填充它时。

HTTP状态代码“409冲突”对我们来说是一个很好的尝试，因为它是定义要求包含足够的信息以便用户识别
.冲突的根源

因此，在其他响应中，如400或404，我们选择409来强制检查请求中的一些注释，这有助于建立一个新的正确的请求。

无论如何，我们的案例是特殊的，因为如果请求不完全正确，我们需要发送一些数据，并且我们需要强制客户端查看消息并了解请求中的错误。

一般来说，如果我们有只是缺少了一些参数，我们会去400和一个缺少参数的数组。但是当我们需要发送更多的信息时，比如一个特定的案例消息，我们希望更确定客户端会处理它，我们就会发送409

小开

进入浏览器设置>盾牌祝辞自动重定向AMP页面

.禁用它，然后重试