我有一组延迟创建的资源。构造这些表示的计算可能会花费几毫秒到几小时不等，具体取决于服务器负载，特定资源和月球相位。
收到的对资源的第一个GET请求在服务器上开始计算。如果计算在几秒钟内完成，则返回计算的表示形式。否则，将返回202“已接受”状态代码，并且客户端必须轮询资源，直到最终表示可用为止。
出现这种现象的原因如下:如果结果在几秒钟内可用，则需要尽快对其进行检索；否则，请执行以下操作。否则，何时可用并不重要。
由于有限的内存和庞大的请求量，NIO和长时间轮询都不是一种选择(即，我无法打开几乎足够的连接，甚至什至无法容纳所有请求；一次“几秒钟”)已通过，我将保留多余的请求)。同样，客户端的限制使得它们不能处理完成回调。最后，请注意，我对创建一个“工厂”资源并没有兴趣，因为额外的往返行程意味着我们使分段实时约束失败的程度超出了期望的范围(此外，这是额外的复杂性；此外，这是一种资源受益于缓存)。
我以为在响应GET请求时返回202“已接受”状态代码存在一些争议，因为我在实践中从未见过它，并且最直观的用法是响应不安全的方法，但是我从来没有发现任何特别令人沮丧的东西。此外，我既不保留安全性又没有幂等性吗？
那么，人们如何看待这种方法呢？
编辑:我应该提到这是针对所谓的业务Web API的，而不是针对浏览器的。
最佳答案
如果它是用于定义明确且有文档证明的API，则202听起来完全适合发生的事情。
如果是用于公共(public)Internet，我会太担心客户端兼容性。我看过这么多if (status == 200)硬编码...。在这种情况下，我将返回200。
另外，RFC并未表明对GET请求使用202是错误的，尽管它在其他代码描述(例如200)中有明显的区别。
关于http-status-codes - 返回202 “Accepted”以响应HTTP GET是否错误？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4099869/