97

我有一组资源，其表示是延迟创建的。构建这些表示的计算可能需要几毫秒到几小时不等，具体取决于服务器负载、特定资源和月相。

为资源收到的第一个 GET 请求启动服务器上的计算。如果计算在几秒钟内完成，则返回计算的表示。否则，将返回 202“已接受”状态代码，并且客户端必须轮询资源，直到最终表示可用。

这种行为的原因如下：如果结果在几秒钟内可用，则需要尽快检索；否则，何时可用并不重要。

由于内存有限和请求数量庞大，NIO 和长轮询都不是一个选项（即，我无法保持几乎足够的连接打开，甚至无法将所有请求都放入内存；一旦“几秒钟”已经过去了，我坚持多余的请求）。同样，客户端的限制使得它们无法处理完成回调。最后，请注意，我对创建一个 POST 到的“工厂”资源不感兴趣，因为额外的往返意味着我们超出了预期的分段实时约束（此外，它是额外的复杂性；而且，这是一个资源受益于缓存）。

我想在响应 GET 请求时返回 202“已接受”状态代码存在一些争议，因为我在实践中从未见过它，它最直观的用途是响应不安全的方法，但我从来没有发现任何特别令人沮丧的东西。此外，我不是同时保持安全性和幂等性吗？

那么，人们如何看待这种方法呢？

编辑：我应该提到这是针对所谓的业务 Web API 的——而不是针对浏览器的。

4

4 回答 4

71

如果它是用于定义良好且文档化的 API，那么202听起来完全适合正在发生的事情。

如果是用于公共互联网，我会太担心客户端的兼容性。我见过这么多if (status == 200)硬编码......在这种情况下，我会返回一个200.

此外，RFC没有指出使用 202 进行 GET 请求是错误的，但它在其他代码描述（例如 200）中做出了明确的区分。

请求已被接受处理，但处理尚未完成。

于 2010-11-04T18:23:47.023 回答
21

我们为最近的一个应用程序执行此操作，一个客户端（自定义应用程序，而不是浏览器）发布了一个查询，服务器将返回 202，并带有一个指向正在发布的“作业”的 URI - 客户端将使用该 URI 来轮询结果 - 这似乎很适合正在做的事情。

无论如何，这里最重要的是记录您的服务/API 是如何工作的，以及 202 的响应意味着什么。

于 2010-11-04T18:31:01.977 回答
12

据我所知 - GET 应该在不修改服务器的情况下返回资源。也许活动会被记录或者你有什么，但请求应该可以重新运行并得到相同的结果。

另一方面，POST 是更改服务器上某些内容的状态的请求。插入记录，删除记录，运行作业，诸如此类。202 适用于返回但未完成的 POST，但不是真正的 GET 请求。

这一切都非常清教徒并且在野外没有很好地实践，所以返回 202 可能是安全的。GET 应该返回 200。如果完成，POST 可以返回 200，如果没有完成，则返回 202。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

于 2010-11-04T18:41:05.673 回答
0

如果资源应该具有由 ID 明确指定的实体表示（与问题中所述的“工厂”资源相反），我建议使用 GET 方法，并且在当实体/表示由于延迟创建或任何其他临时情况而不可用时，请使用更合适的 503 Service Unavailable 响应代码，该代码实际上是为此类情况设计的。

原因可以在 HTTP 本身的 RFC 中找到（请验证 503 响应代码的描述）以及许多其他资源。

请与暂时不可用页面的 HTTP 状态代码进行比较。尽管这个问题是关于一个不同的用例，但它实际上与 HTTP 的完全相同的特性有关。

于 2018-11-28T10:53:23.497 回答