返回 HTTP 409 是否适合验证检查？答案

【问题标题】：Is returning HTTP 409 appropriate for a validation check?返回 HTTP 409 是否适合验证检查？
【发布时间】：2012-06-29 07:04:53
【问题描述】：

我有一项服务，必须先检查一些验证规则，然后才能进行特定操作。

例如，如果未满足所有验证规则，则客户端不应生成可打印的报告。

但是，单个客户端可能没有所有必需的信息（该用户可能只能访问用于确定验证成功的数据子集），因此必须向服务器发送请求：基本上"是thing 在start 和finish 之间有效"。

响应将是某种指示VALID: FEEL FREE TO CONTINUE 的令牌，或者是验证失败原因的列表，可以呈现给用户。

很明显，成功的验证将返回200 OK。但我不认为成功状态码适合验证失败。我倾向于409 Conflict，但我只用它来拒绝PUT 或POST。 409 表示验证失败是否有效（窃笑），还是有更好的方法？

注意：执行的操作并未在服务器上执行，因此跳过此检查并尝试该操作，在禁止操作的情况下使用 403 不是一个选项。

【问题讨论】：

您已向服务器请求验证信息。它已经遵守了。对我来说感觉很成功（从 HTTP 的角度来看）
Damien_The_Unbeliever：如果你把这个放到答案中，我会接受。
我不知道这有什么大不了的？您可以使用409 进行验证。但只有在一种情况下，如果用户试图创建一个已经存在的资源，因此conflict。
...这里不是这样。请求本身已成功，但报告验证失败。就像公认的答案说的那样。您的评论没有任何价值。

标签： validation http http-status-codes

【解决方案1】：

您已向服务器发送请求以执行验证。它已成功执行所述验证。从 HTTP 的角度来看，该请求的格式正确，并且由服务器正确处理。

所以我想说返回任何 HTTP 错误代码都是不正确的。

这个答案继续收到反对票，我不完全确定为什么（似乎没有一个反对票的人留下任何 cmets）。通过与 OP 的大量反复，我们确定此请求/响应的整个点是执行验证。服务器收到请求，执行请求执行的验证，并将验证过程的结果返回给调用者。

客户端发送此请求绝对没有问题。

服务器理解请求。

请求有效（从 HTTP 角度来看）。

服务器可以处理请求。

服务器执行了 100% 的预期活动，并返回处理请求后产生的结果。

这就是为什么，正如我所说，我不认为 HTTP 错误代码是合适的。

即想象一下，服务器公开了一个验证电子邮件地址的端点（对于您希望说可以执行验证的任何特定形式）。它收到一个请求说“验证 abc@invalid.org”并产生一个响应说“我查看了这个电子邮件地址，我希望你告诉用户我无法获得无效的有效 DNS 响应.org”。如果人们认为这里的 200 响应不正确，我希望喜欢了解他们的推理。

【讨论】：

-1 403 Forbidden The server understood the request, but is refusing to fulfill it. 和 410 Gone The requested resource is no longer available at the server and no forwarding address is known. 是请求格式正确且处理正确的两个错误。
另外，您如何区分数据已保存和数据无效？阅读内容会使状态码的使用变得毫无意义。有大量关于 REST API 的讨论，到目前为止，我还没有看到任何建议返回 200 OK。
@Stijn - 根据我对原始问题的阅读，这不是在同一操作中对它们进行进一步处理之前执行的验证。该服务（端点）有一个目的 - “请为我运行一些验证”。如果它已经运行了验证（无论结果如何），它就完成了它打算做的所有工作。它不是拒绝服务，所以403似乎是错误的。
我并不是建议为此使用 403，只是给出与您的陈述不符的示例。为混乱道歉。
409 是另一种数据有效且已处理但操作被拒绝的情况。在这种情况下，我们想知道继续进行是否安全。我可能更愿意执行所需的操作，然后在无法完成时返回错误，但如果我们准备好执行所述操作，则有必要在导致“最终”操作的更改之后指出。

【解决方案2】：

虽然它仍在提议的标准中定义，但422 Unprocessable Entity 是适当的状态。

422 (Unprocessable Entity) 状态码表示服务器理解请求实体的内容类型（因此 415（不支持的媒体类型）状态码不合适），并且请求实体的语法是正确的（因此是 400 (Bad Request) 状态码不合适）但无法处理包含的说明。

例如，如果 XML 请求正文包含格式正确（即语法正确），但是语义错误的 XML 指令。

参考资料：

【讨论】：

我认为您错过了调用的整个目的是执行验证的部分。在这种情况下，指示错误（当请求格式正确并且我们可以执行请求的验证时）似乎是错误的。
@Damien_The_Unbeliever 我仍然认为在出现验证错误时返回 200 不是一个好方法。您仍然需要解析内容以了解验证是否成功。
@Stijn 是的，这是我关心的问题。然而，请求本身是成功的：只是它是无效的。

【解决方案3】：

如果您的 HTTP 资源的状态是“介于开始和结束之间”以解释您在这个公认的较老问题上的话，我想投票支持返回状态 202。它的优势是 2- - “成功”类型的响应，所以笨拙的客户端不会认为它是一个损坏的页面，它在 HTTP 1.1 规范中声明的目的听起来像你想要的（尽管许多状态代码定义非常模糊）。

Specification Link

摘录：

202 Accepted

The request has been accepted for processing, but the processing has not been 
completed. The request might or might not eventually be acted upon, as it 
might be disallowed when processing actually takes place...

The 202 response is intentionally non-committal. Its purpose is to allow a server 
to accept a request for some other process (perhaps a batch-oriented process 
that is only run once per day) without requiring that the user agent's 
connection to the server persist until the process is completed. The entity 
returned with this response SHOULD include an indication of the request's 
current status and either a pointer to a status monitor or some estimate of 
when the user can expect the request to be fulfilled.

【讨论】：

你引文的第二段让我远离202。验证是否通过或成功是已知的。问题的症结在于请求成功，只是请求所提问题的答案是“验证失败”（或通过）。

【解决方案4】：

通常情况下，如果不确切知道自己在做什么、如何以及为什么等，很难给出准确的建议。例如：

我有一项服务，其中必须先检查一些验证规则应该能够进行特定的操作。

此服务是否提供本地代码？如果是这样，您应该向本地代码抛出异常或返回正常的内容。
它是否与 API 请求相关联？如果从表面上看是这样，我不明白您为什么要在单独的 REST 调用上进行验证，而不是在一个请求中完成所有操作。

但是，个别客户可能无法满足所有要求信息（该用户可能只能访问数据的子集用于确定验证成功），因此请求必须是发送到服务器：基本上“在开始和完成”。

例如，我在做假设，但是例如，如果他们拥有所有必要的数据等，您可以让他们提出他们会提出的请求，并在那时进行验证。

响应将是某种指示 VALID 的标记：随意继续，或验证失败原因列表，即可以呈现给用户。

这就是为什么我建议我所拥有的，因为您的上述要求是：

向 API 发送请求，API 执行 Validation 并返回响应；
如果响应显示有效，则用户发送下一个响应以执行实际操作；
如果响应显示无效，则用户必须执行某些操作并重试，直到获得有效响应，然后他们仍必须执行实际操作；

替代方案：

向 API 发送请求，执行验证，如果有效则执行此操作，否则返回指示无效状态的响应；
用户进行更改后，再次只需发送一个请求以进行验证和实际操作；

注意：执行的操作不是在服务器上执行的，所以跳过此检查，并尝试执行该操作，其中包含 403 禁止操作的情况不是一种选择。

如果这不是任何类型的 pf 远程/API 请求，那么我建议不要使用 HTTP 代码。这都是在同一个代码库中完成的吗？如果是这样，您的验证中会出现异常或布尔值等，以便向用户提供消息。

【讨论】：

【解决方案5】：

我认为，只要您没有将代码误用于非预期的事情，那么它实际上归结为偏好和意见。 409 可能可以用于验证失败，尽管我认为我个人更喜欢 200 以验证错误作为响应。我认为这让开发人员更容易检查常见的通信错误，例如 401 或 500，并在他们不必担心验证他们发送的数据之前进行处理。

【讨论】：

我不完全同意。 409 暗示（对我而言）我们与服务器通信良好：但我们的请求会导致存储无效数据（例如）。但是，在这种情况下，我同意应该返回 200 OK，因为验证请求处理正常。
一般来说，最好使用 HTTP 200 和响应中的某种错误代码来处理不是 HTTP 通信错误的错误。否则客户端可能会将您的响应误解为您的服务器有问题。
当数据格式正确时发回 409，但业务逻辑检查失败会使您的测试失败。这显然不是通信失败，而是验证错误。我认为在这种情况下，响应应该确实是 200，但恕我直言，您的一揽子陈述具有误导性。
很公平，事实上，我想得越多，409 响应可能就可以用作验证失败。我认为这真的归结为意见，只要你是一致的并且有良好的文档，你可以采取任何一种方式。