我有一项服务，必须先检查一些验证规则，然后才能进行特定操作。
例如，如果未满足所有验证规则，则客户端不应生成可打印的报告。
但是，单个客户端可能没有所有必需的信息（该用户可能只能访问用于确定验证成功的数据的子集），因此必须将请求发送到服务器：基本上是“是在thing和start之间有效的finish”。
响应将是表示VALID: FEEL FREE TO CONTINUE的某种令牌，或者是可以显示给用户的验证失败原因列表。
很明显，成功的验证将返回200 OK。但是我不认为成功状态代码适合验证失败。我倾向于409 Conflict，但是我只用它来拒绝PUT或POST。由409指示的验证失败是否有效（更棘手），或者有更好的方法吗？
注意：在服务器上没有执行所执行的操作，因此，在禁止操作的情况下，跳过此检查，仅尝试操作，并以403进行尝试是无法选择的。
您已将请求发送到服务器以使其执行验证。它已成功执行了上述验证。从HTTP角度来看，请求的格式正确，服务器已正确处理。
所以我想返回任何HTTP错误代码都是不正确的。
此答案继续收到反对意见，但我不确定为什么（所有反对意见的人似乎都未发表任何评论）。通过与OP进行大量的来回交互，我们确定此请求/响应的entire点将执行验证。服务器收到请求，执行请求的验证，并将验证过程的结果返回给调用方。
发送此请求的客户端绝对没有错。
服务器理解了请求。
该请求有效（从HTTP角度看。）>
服务器可以处理请求。
服务器执行了本来打算的活动的100％，并返回处理请求后产生的结果。
这就是为什么，正如我所说的，我认为HTTP错误代码不合适。
即想象一下，服务器公开了一个验证电子邮件地址的端点（对于您希望执行验证的任何特定形式）。它收到一个说“ validate [email protected]”的请求，并产生一个回答“我看了看这个电子邮件地址，我想让你告诉用户我无法获得无效的有效DNS响应”。 .org”。如果人们认为此处的200答案不正确，我会love
了解他们的推理。尽管仍在提议的标准中定义，但422 Unprocessable Entity是适当的状态。
[如果您的HTTP资源的状态介于“开始和结束之间”，以解释您对这个公认的较旧问题的说法，我想投票赞成返回状态202。它的优点是可以将2-- “成功”类型的响应，因此一个笨拙的客户端不会认为它是残破的页面，并且它在HTTP 1.1规范中声明的目的听起来像您想要的（尽管许多状态代码定义非常模棱两可）。
在通常情况下，很难在不确切知道您在做什么，怎么做以及为什么等等的情况下提供准确的建议。例如：
我认为，只要您不将代码误用于非预期的内容，那么它实际上取决于偏好和意见。 409可能可以用于验证失败，尽管我个人认为我更喜欢200并带有验证错误作为响应。我认为这使开发人员更容易检查常见的通信错误（例如401或500），并在他们不必担心验证发送的数据之前对其进行处理。