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

从rfc2616:

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

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

当使用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。

我会复制谷歌。

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

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

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

从rfc2616:

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