如果出现以下情况，应该将什么响应代码传递给客户端？
我选择了403。我也发现了以下我觉得可以使用的。
维基百科：
412 前提条件失败： 服务器不满足请求者的前提条件之一 提出要求
如果我应该使用 403 以外的代码，请建议代码。
【问题讨论】：
400 在这两种情况下都是最佳选择。如果您想进一步澄清错误，您可以更改原因短语或添加正文来解释错误。
412 - Precondition failed 用于在使用最后修改日期和 ETag 时的条件请求。
403 - 当服务器希望阻止对资源的访问时使用 Forbidden。
唯一可能的其他选择是 422 - Unprocessable entity。
【讨论】：
我会推荐 422。它不是主要 HTTP 规范的一部分，但它是由公共标准 (WebDAV) 定义的，浏览器应该像对待任何其他 4xx 状态代码一样对待它。
来自RFC 4918：
422（Unprocessable Entity）状态码表示服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此 400 （错误请求）状态代码不合适）但无法处理包含的指令。例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会发生这种错误情况。
【讨论】：
如果无法正确解析请求（包括请求实体/正文），则相应的响应为 400 Bad Request [1]。
RFC 4918 声明 422 Unprocessable Entity 适用于请求实体在语法上格式良好但在语义上错误的情况。因此，如果请求实体出现乱码（例如错误的电子邮件格式），请使用 400；但如果它没有意义（比如@example.com），请使用 422。
如果问题是，如问题中所述，用户名/电子邮件已经存在，您可以使用 409 Conflict [2] 说明冲突，并提示有关如何修复它（在这种情况下，“选择不同的用户名/电子邮件”）。然而，在编写的规范中，403 Forbidden [3] 也可以在这种情况下使用，尽管有关于 HTTP 授权的参数。
412 Precondition Failed [4] 当客户端提供的前置条件请求标头（例如If-Match）评估为假时使用。也就是说，客户请求某些东西并提供了先决条件，完全清楚这些先决条件可能会失败。 412 绝不应该突然出现在客户端上，并且不应该与请求实体相关本身。
【讨论】：
将418 I'm a teapot 返回到明显是精心设计或恶意且“不可能发生”的请求很有趣，例如 CSRF 检查失败或缺少请求属性。
2.3.2 418 我是个茶壶
任何尝试用茶壶冲泡咖啡都会导致错误 代码“418我是一个茶壶”。生成的实体主体可能很短并且 粗壮。
为了保持合理的严肃性，我将有趣的错误代码的使用限制在不直接暴露给用户的 RESTful 端点。
【讨论】：
418 I'm a teapot :)