返回202“Accepted”是否错误响应 HTTP GET？
我有一组资源，其表示是延迟创建的。构建这些表示的计算可能需要几毫秒到几个小时，具体取决于服务器负载、特定资源和月相。
收到的第一个资源 GET 请求将启动服务器上的计算。如果计算在几秒钟内完成，则返回计算的表示。否则，将返回 202“已接受”状态代码，并且客户端必须轮询资源，直到最终表示可用。
造成这种行为的原因如下：如果结果在几秒钟内可用，则需要尽快检索；否则，何时可用并不重要。
由于内存有限和请求量巨大，NIO 和长轮询都不是一个选择（即我无法保持足够的连接打开，甚至无法在内存中容纳所有请求；一旦“几秒钟”过去，我就会坚持多余的请求）。同样，客户端的限制是它们无法处理完成回调。最后，请注意，我对创建一个可以发布到的“工厂”资源不感兴趣，因为额外的往返意味着我们无法满足分段实时约束的要求（而且，它是额外的复杂性；而且，这是一种资源，受益于缓存）。
我想在响应 GET 请求时返回 202“已接受”状态代码存在一些争议，因为我在实践中从未见过它，而且它最直观的用途是响应不安全的方法，但我从未见过发现任何特别令人沮丧的事情。而且，我不是既保证了安全性又保证了幂等性吗？
那么，人们对这种方法有何看法呢？
编辑：我应该提到这是针对所谓的业务 Web API，而不是针对浏览器。
I have a set of resources whose representations are lazily created. The computation to construct these representations can take anywhere from a few milliseconds to a few hours, depending on server load, the specific resource, and the phase of the moon.
The first GET request received for the resource starts the computation on the server. If the computation completes within a few seconds, the computed representation is returned. Otherwise, a 202 "Accepted" status code is returned, and the client must poll the resource until the final representation is available.
The reason for this behavior is the following: If a result is available within a few seconds, it needs to be retrieved as soon as possible; otherwise, when it becomes available is not important.
Due to limited memory and the sheer volume of requests, neither NIO nor long polling is an option (i.e. I can't keep nearly enough connections open, nor even can I even fit all of the requests in memory; once "a few seconds" have passed, I persist the excess requests). Likewise, client limitations are such that they cannot handle a completion callback, instead. Finally, note I'm not interested in creating a "factory" resource that one POSTs to, as the extra roundtrips mean we fail the piecewise realtime constraint more than is desired (moreover, it's extra complexity; also, this is a resource that would benefit from caching).
I imagine there is some controversy over returning a 202 "Accepted" status code in response to a GET request, seeing as I've never seen it in practice, and its most intuitive use is in response to unsafe methods, but I've never found anything specifically discouraging it. Moreover, am I not preserving both safety and idempotency?
So, what do folks think about this approach?
EDIT: I should mention this is for a so-called business web API--not for browsers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果它是一个定义良好且有文档记录的 API，那么
202听起来完全适合正在发生的事情。如果是公共互联网，我会太担心客户端兼容性。我见过很多
if (status == 200)硬编码......在这种情况下，我会返回200。此外，RFC 没有表明使用 202 进行 GET 请求是错误，而它在其他代码描述中做出了明确的区分（例如200）。
If it's for a well-defined and -documented API,
202sounds exactly right for what's happening.If it's for the public Internet, I would be too worried about client compatibility. I've seen so many
if (status == 200)hard-coded.... In that case, I would return a200.Also, the RFC makes no indication that using 202 for a GET request is wrong, while it makes clear distinctions in other code descriptions (e.g. 200).
我们为最近的一个应用程序执行了此操作，客户端（自定义应用程序，而不是浏览器）发布了一个查询，服务器将返回 202，其中包含正在发布的“作业”的 URI - 客户端将使用该 URI 来轮询结果——这似乎与正在做的事情非常吻合。
无论如何，这里最重要的事情是记录您的服务/API 的工作方式，以及 202 响应的含义。
We did this for a recent application, a client (custom application, not a browser) POST'ed a query and the server would return 202 with a URI to the "job" being posted - the client would use that URI to poll for the result - this seems to fit nicely with what was being done.
The most important thing here is anyway to document how your service/API works, and what a response of 202 means.
据我所知 - GET 应该返回资源而不修改服务器。也许活动会被记录或者发生什么，但是请求应该可以重新运行并得到相同的结果。
另一方面，POST 是更改服务器上某些内容的状态的请求。插入记录、删除记录、运行作业等等。 202 适合返回但未完成的 POST，但实际上不是 GET 请求。
这一切都非常清教徒，在野外没有得到很好的实践，所以返回 202 可能是安全的。GET 应该返回 200。POST 如果完成则返回 200，如果未完成则返回 202。
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
From what I can recall - GET is supposed to return a resource without modifying the server. Maybe activity will be logged or what have you, but the request should be rerunnable with the same result.
POST on the other hand is a request to change the state of something on the server. Insert a record, delete a record, run a job, something like that. 202 would be appropriate for a POST that returned but isn't finished, but not really a GET request.
It's all very puritan and not well practiced in the wild, so you're probably safe by returning 202. GET should return 200. POST can return 200 if it finished or 202 if it's not done.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
如果资源应该具有由 ID 明确指定的实体的表示（而不是问题中描述的“工厂”资源），我建议继续使用 GET 方法，并在当实体/表示由于延迟创建或任何其他临时情况而不可用时，请使用更合适的 503 服务不可用响应代码，该代码实际上是为此类情况设计的。
其原因可以在 HTTP 本身的 RFC（请验证 503 响应代码的描述）以及许多其他资源中找到。
请与暂时不可用页面的 HTTP 状态代码进行比较。尽管该问题涉及不同的用例，但它实际上与 HTTP 的完全相同的功能相关。
In case of a resource that is supposed to have a representation of an entity that is clearly specified by an ID (as opposed to a "factory" resource, as described in the question), I recommend staying with the GET method and, in a situation when the entity/representation is not available because of lazy-creation or any other temporary situation, use the 503 Service Unavailable response code that is more appropriate and was actually designed for situations like this one.
Reasoning for this can be found in the RFCs for HTTP itself (please verify the description of the 503 response code), as well as on numerous other resources.
Please compare with HTTP status code for temporarily unavailable pages. Although that question is about a different use case, it actually relates to the exact same feature of HTTP.