返回202“已接受"是否错误?响应HTTP GET? [英] Is it wrong to return 202 "Accepted" in response to HTTP GET?

问题描述

我有一组资源，这些资源的表示形式是延迟创建的.构造这些表示的计算可能要花费几毫秒到几小时不等，具体取决于服务器负载，特定资源和月球相位.

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.

收到的对资源的第一个GET请求开始在服务器上进行计算.如果计算在几秒钟内完成，则返回计算的表示形式.否则，将返回202已接受"状态代码，并且客户端必须轮询资源，直到最终表示可用为止.

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.

由于内存有限和大量请求，NIO和长时间轮询都不是一种选择(即，我无法打开几乎足够的连接，甚至都无法容纳所有连接)内存中的请求；一旦几秒钟"过去，我将保留多余的请求).同样，客户端的限制使得它们不能处理完成回调.最后，请注意，我对创建一个工厂"资源并没有兴趣，因为额外的往返行程意味着我们使分段实时约束失败的程度超出了期望的范围(此外，这是额外的复杂性；此外，这是一种资源受益于缓存).

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).

我想象在响应GET请求时返回202已接受"状态代码存在一些争议，因为我在实践中从未见过，并且最直观的用法是响应不安全的方法，但是我从来没有发现任何特别令人沮丧的东西.而且，我既不保留安全性又没有幂等性吗?

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?

编辑:我应该提到这是针对所谓的业务网络API的，而不是针对浏览器的.

EDIT: I should mention this is for a so-called business web API--not for browsers.

推荐答案

如果它用于定义明确并有详细说明的API，则202听起来完全正确.

If it's for a well-defined and -documented API, 202 sounds exactly right for what's happening.

如果用于公共Internet，我会太担心客户端兼容性.我见过很多if (status == 200)硬编码....在那种情况下，我会返回200.

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 a 200.

此外， RFC 并不表示将202用作GET请求是错误的，尽管它在其他代码描述(例如200)中有明显的区别.

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).

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

The request has been accepted for processing, but the processing has not been completed.

这篇关于返回202“已接受"是否错误?响应HTTP GET?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！