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

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

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

当使用webHttpBinding时，. net中的WCF API通过返回一个HTTP 404“Endpoint Not Found”错误来处理丢失的参数。

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

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

10.4.5 404未找到 服务器没有发现任何与Request-URI匹配的内容。没有 说明这种情况是暂时的还是 永久性的。

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

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

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

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

我会复制谷歌。

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

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

参考:w3.org/Protocols/

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

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

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

根据规范，状态422似乎最合适。

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

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

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