无效数据的REST响应代码

Question

如果出现以下情况，应将哪些响应代码传递给客户？

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

我选择了403.我也发现以下我认为可以使用。

  

百科：

     

412前提条件失败：       服务器不符合请求者的前提条件之一   提出要求

建议代码，如果我应该使用403以外的其他代码。

Answer 1

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

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

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

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

Answer 2

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

来自RFC 4918：

  

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

Answer 3

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

RFC 4918声明 422 Unprocessable Entity 适用于请求实体在语法上格式正确但语义错误的情况。因此，如果请求实体出现乱码（如错误的电子邮件格式），请使用400;但如果它没有意义（如@example.com），请使用422。

如果问题是，如问题中所述，用户名/电子邮件已存在，您可以使用 409冲突 [2]来说明冲突，并且提示如何解决它（在这种情况下，“选择一个不同的用户名/电子邮件”）。但是在编写的规范中，在这种情况下也可以使用 403 Forbidden [3]，尽管有关HTTP授权的参数。

412前提条件失败 [4]用于客户端提供的评估的前置条件请求标头（例如If-Match）假。也就是说，客户端请求了一些东西并提供了先决条件，完全清楚这些先决条件可能会失败。 412永远不应该突然出现在客户端上，并且不应该与请求实体本身相关。

Answer 4

将418 I'm a teapot返回到明显制作或恶意且“无法发生”的请求，例如CSRF检查失败或缺少请求属性，这很有趣。

  

2.3.2 418我是一个茶壶

     

任何尝试用茶壶冲泡咖啡都会导致错误   代码“418我是一个茶壶”。由此产生的实体可能很短   粗壮。

为了使其保持相当严重，我将有趣的错误代码的使用限制为不直接向用户公开的RESTful端点。