REST响应代码以获取无效数据

在以下情况下，应将什么响应代码传递给客户端？

1. 用户注册时传递的数据无效，例如电子邮件格式错误
2. 用户名/电子邮件已经存在

我选择了403。我还发现我觉得可以使用。

维基百科：

412先决条件失败：服务器不满足请求者提出的先决条件之一

如果我不使用403，建议输入代码。

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

412-使用上次修改的日期和ETag时，前提条件失败用于前提条件请求。

403-当服务器希望阻止访问资源时，使用“禁止”。

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

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

从RFC 4918：

422（不可处理实体）状态代码表示服务器理解请求实体的内容类型（因此415（不支持的媒体类型）状态代码不合适），并且请求实体的语法正确（因此400（错误请求） ）状态代码不合适），但无法处理其中的说明。例如，如果XML请求主体包含格式正确（即，语法正确）但语义错误的XML指令，则可能发生此错误情况。

如果无法正确解析请求（包括请求实体/主体），则相应的响应为400 Bad Request [ 1 ]。

RFC 4918规定，当请求实体在语法上格式正确，但在语义上错误时，422不可处理实体适用。因此，如果请求实体出现乱码（例如错误的电子邮件格式），请使用400；但是如果它没有意义（例如@example.com），请使用422。

如果问题是，如问题中所述，用户名/电子邮件已经存在，则可以使用409 Conflict [ 2 ]以及对冲突的描述以及如何解决的提示（在这种情况下，“选择一个不同的用户名/电子邮件”）。但是，在编写的规范中，尽管有关于HTTP授权的争论，在这种情况下也可以使用403 Forbidden [ 3 ]。

412前提条件失败 [ 4 ]当客户端提供的前提条件请求标头（例如If-Match）评估为false时使用。也就是说，客户请求了一些东西并提供了前提条件，完全知道这些前提条件可能会失败。412绝不应突然出现在客户端上，也不应与请求实体本身相关。

返回418 I'm a teapot显然是经过精心设计或恶意并且“不可能发生”的请求，例如CSRF检查失败或缺少请求属性，这很有趣。

2.3.2 418我是茶壶

任何尝试用茶壶冲泡咖啡的操作都将导致错误代码“ 418我是茶壶”。生成的实体主体可能短而结实。

为了使其合理，我将有趣的错误代码的使用限制在未直接暴露给用户的RESTful端点上。