我在想412（前提条件失败），但是可能会有更好的标准？
#1楼
根据该规范，状态422最合适。
422（不可处理实体）状态代码表示服务器了解请求实体的内容类型（因此415（不支持的媒体类型）状态代码不合适），并且请求实体的语法正确（因此400（错误请求） ）状态代码不合适），但无法处理其中的说明。 例如，如果XML请求主体包含格式正确（即，语法正确）但语义错误的XML指令，则可能发生此错误情况。
他们指出，格式错误的xml是语法错误的示例（要求400）。 格式错误的查询字符串似乎与此相似，因此400似乎不适用于缺少参数的格式正确的查询字符串。
UPDATE @DavidV正确地指出此规范适用于WebDAV，而不适用于核心HTTP。 但是，由于缺少更好的状态代码，一些流行的非WebDAV API仍在使用422（ 请参阅参考资料 ）。
#2楼
对于那些感兴趣的人，在这种情况下，Spring MVC（至少3.x）返回400，这对我来说似乎是错误的。
我测试了多个Google网址（accounts.google.com），并删除了必需的参数，在这种情况下，它们通常返回404。
我会复制Google。
#3楼
我会选择403。
从RFC 2616-超文本传输协议-HTTP / 1.1
403禁止
服务器理解了该请求，但拒绝执行该请求。 授权将无济于事，不应重复该请求。 如果请求方法不是HEAD，并且服务器希望公开为什么未满足请求，则应在实体中描述拒绝原因。 如果服务器不希望将此信息提供给客户端，则可以改用状态代码404（未找到）。
您应在回复中说明失败的原因。 如果您不想这样做，请使用404。
#4楼
如果所需参数中的某些内容与API端点所需的内容不匹配（例如密码太短），我通常会选择422（无法处理的实体），但是对于缺少的参数，我会选择406（无法接受）。
#5楼
在我们的一个API项目中，我们决定为某个请求设置409状态，因为由于缺少参数而无法以100％的比例完全填充它。
HTTP状态代码“ 409冲突”对我们来说是一个很好的尝试，因为它的定义要求包括足够的信息供用户识别冲突的来源。
因此，在其他响应（例如400或404）中，我们选择409来强制需要查看请求中的一些注释，这有助于建立新的正确请求。
无论如何，我们的情况都是特别的，因为如果请求不完全正确，我们需要发送一些数据前夕，并且我们需要强制客户端查看消息并了解请求中的错误。
通常，如果我们只有一些缺失的参数，我们可以选择400和缺失参数的数组。 但是，当我们需要发送更多信息（例如特殊情况的消息）并且希望确保客户会妥善处理时，我们发送409
来源：oschina
链接：https://my.oschina.net/stackoom/blog/3168509