11

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

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

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

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

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

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

4

5 回答 5

29

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

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

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

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

服务器理解请求。

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

服务器可以处理请求。

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

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

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

于 2012-08-16T07:54:36.363 回答
11

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

422（Unprocessable Entity）状态码意味着服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此是 400（Bad Request） ) 状态码不合适）但无法处理包含的指令。

例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会出现这种错误情况。

参考：

于 2013-02-27T16:15:33.323 回答
0

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

规格链接

摘抄：

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.
于 2013-06-20T14:49:46.850 回答
0

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

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

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

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

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

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

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

  1. 向 API 发送请求，API 执行 Validation 并返回响应；
  2. 如果响应显示有效，则用户发送下一个响应以执行实际操作；
  3. 如果响应显示无效，那么用户必须做一些事情并重试，直到他们得到有效的响应，然后他们仍然必须做实际的事情；

选择：

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

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

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

于 2019-10-13T18:38:42.290 回答
-1

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

于 2012-08-15T23:55:21.417 回答