我有一组资源，其表示形式是延迟创建的。构建这些表示的计算可能需要几毫秒到几个小时，具体取决于服务器负载、特定资源和月相。
收到的第一个资源 GET 请求将启动服务器上的计算。如果计算在几秒钟内完成，则返回计算的表示。否则，将返回 202“已接受”状态代码，并且客户端必须轮询资源，直到最终表示可用。
此行为的原因如下:如果结果在几秒钟内可用，则需要尽快检索；否则，何时可用并不重要。
由于内存有限和请求量巨大，NIO 和长轮询都不是一个选择(即我无法保持足够的连接打开，甚至无法容纳所有的连接)内存中的请求；一旦“几秒钟”过去，我就会保留多余的请求)。同样，客户端的限制是它们无法处理完成回调。最后，请注意，我对创建一个 POST 到的“工厂”资源不感兴趣，因为额外的往返意味着我们无法满足分段实时约束的要求(此外，它是额外的复杂性；而且，这是一种资源，从缓存中受益)。
我认为在响应 GET 请求时返回 202“已接受”状态代码存在一些争议，因为我在实践中从未见过它，而且它最直观的用途是响应不安全的方法，但我从来没有发现任何具体阻碍它的事情。而且，我不是既保证了安全性又保证了幂等性吗？
那么，人们对这种方法有何看法？
编辑:我应该提到这是针对所谓的业务 Web API，而不是针对浏览器。
最佳答案
如果它是一个定义明确且有文档记录的 API，那么 202 听起来完全适合正在发生的事情。
如果是针对公共(public)互联网，我会太担心客户端兼容性。我见过很多 if (status == 200) 硬编码......在这种情况下，我会返回 200。
此外，RFC没有表明使用 202 表示 GET 请求是错误的，但它在其他代码描述中(例如 200)做出了明确的区分。
The request has been accepted for processing, but the processing has not been completed.
关于http-status-codes - HTTP GET 响应返回 202 "Accepted"是否错误？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4099869/