问未通过验证的REST HTTP状态代码或无效重复？

00,300,400,500都是非常通用的。如果你想通用，400是确定的。

422被越来越多的API使用，甚至被开箱即用的Rails使用。

无论您选择哪种状态码，都会有人不同意。但我更喜欢422，因为我认为“400 +文本状态”太泛化了。另外，您还没有充分利用JSON就绪解析器。相反，具有JSON响应的422非常明确，并且可以传达大量的错误信息。

说到JSON响应，我倾向于在这种情况下对Rails错误响应进行标准化，即：

{

    "errors" :

    { 

        "arg1" : ["error msg 1", "error msg 2", ...]

        "arg2" : ["error msg 1", "error msg 2", ...]

    }

}

这种格式非常适用于表单验证，在“错误报告丰富性”方面，我认为这是最复杂的情​​况。如果你的错误结构是这样，它可能会处理你所有的错误报告需求。

验证失败：403禁止（“服务器理解请求，但拒绝履行）”。与流行的观点相反，RFC2616没有说“403只是用于失败的认证”，而是“403：我知道你想要什么，但是我不会这样做”。这种情况可能会或可能不会由于身份验证。

尝试添加一个副本：409冲突（“由于与资源的当前状态发生冲突，请求无法完成”）

您应该在响应头文件和/或正文中给出更详细的解释（例如使用自定义头文件X-Status-Reason: Validation failed）。