无效数据的REST响应代码

小开

最佳答案

在这两种情况下，400是最好的选择。如果您想进一步澄清错误，您可以更改原因短语或包含正文来解释错误。

412 -当使用最后修改日期和ETags时，前置条件失败用于条件请求。

403 -当服务器希望阻止对资源的访问时，使用Forbidden。

唯一可能的其他选择是422 -不可处理实体。

小开

我推荐422。它不是主要HTTP规范的一部分，但它是由一个公共标准(WebDAV)定义的，浏览器应该像对待任何其他4xx状态代码一样对待它。

从RFC 4918:

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

小开

如果请求不能被正确解析(包括请求实体/主体)，则适当的响应是400错误请求 [1]。

RFC 4918声明当请求实体在语法上格式良好，但语义错误时，422不可处理实体是适用的。因此，如果请求实体是乱码(就像一个糟糕的电子邮件格式)，使用400;但如果它没有意义(比如@example.com)，则使用422。

如果问题是，如问题中所述，用户名/电子邮件已经存在，您可以使用409年冲突 [2]与冲突的描述，并提示如何修复它(在这种情况下，&;选择一个不同的用户名/电子邮件&;)。然而，在编写的规范中，403年被禁止的 [3.]也可以在这种情况下使用，尽管有关于HTTP授权的参数。

当客户提供的前置条件请求头(例如If-Match)计算为false时使用412前置条件失败 [4]。也就是说，客户请求了一些东西，并提供了先决条件，并且完全知道这些先决条件可能会失败。412永远不应该突然出现在客户端，并且不应该与请求实体本身相关。

小开

将418 I'm a teapot返回给明显是精心制作的或恶意的并且“不可能发生”的请求是有趣的，例如CSRF检查失败或缺少请求属性。

我是一个茶壶
任何用茶壶冲泡咖啡的尝试都会导致错误代码“我是茶壶”。产生的实体体可以是短的和胖胖。< / p >

为了保持合理的严重性，我将有趣的错误代码的使用限制在不直接向用户公开的RESTful端点上。