Question

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

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

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

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

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

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

Answer 1

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

所以我要说返回任何HTTP错误代码都是错误的。

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

发送此请求的客户端完全没有问题。

服务器理解请求。

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

服务器可以处理请求。

服务器执行了100％的活动，并返回处理请求时产生的结果。

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

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

Answer 2

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

422（不可处理实体）状态代码表示服务器   了解请求实体的内容类型（因此a   415（不支持的媒体类型）状态代码不合适），和   请求实体的语法是正确的（因此是400（错误请求）   状态代码不合适但是无法处理包含的内容   指令。

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

参考文献：

Answer 3

我认为，只要你没有滥用代码而不是某些意图，那么它实际上归结为偏好和意见。 409可能可以用于验证失败，但我认为我个人更喜欢200，验证错误作为响应。我认为这使开发人员更容易检查常见的通信错误，如401或500，并在他们不得不担心验证他们发送的数据之前处理它们。

Answer 4

如果您的HTTP资源的状态位于“开始和结束之间”的某个位置，以便在这个公认的旧问题上解释您的话，我想投票支持返回状态202.它具有成为2的优势 - “成功”类型响应，因此dumber客户端不会认为它是一个损坏的页面，它在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.

Answer 5

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

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

此服务是否提供本地代码？如果是这样，则应将本地代码引发异常或返回正常内容。
是否与API请求绑定？如果从表面上看是这样，那么我看不到为什么要在一个单独的REST调用上进行验证，而不是在一个请求中全部完成。

但是，单个客户可能没有满足所有要求信息（该用户可能只能访问数据的子集用于确定验证是否成功），因此必须发送到服务器：基本上“在启动和启动之间有效完成”。

举例来说，我正在做假设，但例如，您可以让他们提出请求（如果他们拥有所有必要的数据等），然后在那一点进行验证。

响应将是某种表示VALID的令牌：随时继续，或验证失败原因列表，可以呈现给用户。

这就是为什么我建议我拥有的原因，因为您的读物像这样，要求是：

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

替代：

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

注意：执行的操作未在服务器上执行，因此跳过此检查，仅尝试执行操作，并在其中输入403 禁止采取行动的情况是不可行的。

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

返回HTTP 409是否适合进行验证检查？

5 个答案: