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

RFC 4918指出422 Unprocessable Entity适用于请求实体在语法上格式良好，但语义错误的情况。因此，如果请求实体是乱码(就像一个糟糕的电子邮件格式)，使用400;但如果没有意义(如@example.com)，则使用422。

如果问题是，如问题中所述，用户名/电子邮件已经存在，您可以使用409 Conflict[2]，其中包含冲突的描述，以及如何修复它的提示(在本例中，“选择不同的用户名/电子邮件”)。然而，在编写的规范中，403 Forbidden[3]也可以在这种情况下使用，尽管有关于HTTP授权的参数。

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

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

来自RFC 4918:

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

返回418 I'm a teapot(我是茶壶)对那些明显是精心制作的或恶意的且“不可能发生”的请求，例如CSRF检查失败或缺少请求属性，这很有趣。

我是一个茶壶 任何用茶壶煮咖啡的尝试都会导致错误 代号“418我是茶壶”。产生的实体体可以是短的和 胖胖。

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

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

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

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

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

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

RFC 4918指出422 Unprocessable Entity适用于请求实体在语法上格式良好，但语义错误的情况。因此，如果请求实体是乱码(就像一个糟糕的电子邮件格式)，使用400;但如果没有意义(如@example.com)，则使用422。

如果问题是，如问题中所述，用户名/电子邮件已经存在，您可以使用409 Conflict[2]，其中包含冲突的描述，以及如何修复它的提示(在本例中，“选择不同的用户名/电子邮件”)。然而，在编写的规范中，403 Forbidden[3]也可以在这种情况下使用，尽管有关于HTTP授权的参数。

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