对无效数据的REST响应代码
在下列情况下应该将什么响应代码传递给客户端？
- 用户注册时传递的数据无效，如错误的电子邮件格式
- 用户名/电子邮件已存在
我select了403.我也发现以下我觉得可以使用。
维基百科：
412先决条件失败：服务器不符合请求者提出请求的前提条件之一
build议如果我使用403以外的代码。
400是两种情况下的最佳select。 如果您想进一步澄清错误，您可以更改原因词组或包含一个正文来解释错误。
412 – 使用最后修改date和ETags时，先决条件失败用于条件请求。
403 – 服务器希望阻止访问资源时使用禁止。
唯一可能的select是422 – 不可处理的实体。
我会推荐422.它不是主要HTTP规范的一部分，但它是由一个公共标准（WebDAV）定义的，它应该被浏览器视为与任何其他4xx状态码相同。
从RFC 4918 ：
422（不可处理的实体）状态码意味着服务器理解请求实体的内容types（因此415（不支持的媒体types）状态码是不合适的），并且请求实体的语法是正确的（因此400（错误的请求）状态码不合适），但无法处理包含的说明。 例如，如果XML请求主体包含格式正确（即，语法正确），但语义错误的XML指令，则可能出现此错误情况。
如果请求不能被正确parsing（包括请求实体/主体），则适当的响应是400错误请求 [ 1 ]。
RFC 4918指出，当请求实体在语法上格式良好时， 422不可处理实体是适用的，但在语义上是错误的。 所以，如果请求实体是乱码（如不良的电子邮件格式）使用400; 但如果它没有意义（如@example.com ）使用422。
如果问题是，如问题中所述，用户名/电子邮件已经存在，您可以使用冲突描述[40]和关于如何解决它的提示（在这种情况下，“select不同的用户名/电子邮件“）。 然而，在这个规范中， 403 Forbidden [ 3 ]也可以用在这种情况下，尽pipe有关HTTP授权的争论。
412前提条件失败 [ 4 ] 在客户端提供的前提条件请求头（如If-Match ）计算结果为false时使用。 也就是说，客户要求一些东西，并提供先决条件，充分了解这些先决条件可能会失败。 412不应该突然出现在客户身上，而且也不应该与请求实体本身有关 。
这是有趣的返回418 I'm a teapot明显的精心制作或恶意和“不能发生”，如失败的CSRF检查或缺less请求属性的请求418 I'm a teapot 。
2.3.2 418我是一个茶壶
任何尝试用茶壶冲泡咖啡都会导致错误代码“418我是茶壶”。 由此产生的实体主体可能短而粗壮。
为了保持合理的严肃性，我将有趣的错误代码的使用限制在不直接暴露给用户的RESTful端点上。
