我有一组延迟创建的资源。构造这些表示的计算可能要花费几毫秒到几小时不等，具体取决于服务器负载，特定资源和月球相位。
收到的对资源的第一个GET请求开始在服务器上进行计算。如果计算在几秒钟内完成，则返回计算的表示形式。否则，将返回202“已接受”状态代码，并且客户端必须轮询资源，直到最终表示可用为止。
出现这种现象的原因如下：如果结果在几秒钟内可用，则需要尽快对其进行检索。否则，何时可用并不重要。
由于有限的内存和庞大的请求量，NIO或长时间轮询都不是一种选择（即，我无法打开几乎足够的连接，甚至什至无法容纳所有请求；一次“几秒钟”）已通过，我将保留多余的请求）。同样，客户端的限制使得它们不能处理完成回调。最后，请注意，我对创建一个“工厂”资源并没有兴趣，因为额外的往返行程意味着我们使分段实时约束失败的程度超出了期望（此外，这是额外的复杂性；此外，这是一种资源受益于缓存）。
我以为在响应GET请求时返回202“已接受”状态代码存在一些争议，因为我在实践中从未见过这种方法，并且最直观的用法是响应不安全的方法，但是我从未发现任何特别令人沮丧的东西。此外，我既不保留安全性又没有幂等性吗？
那么，人们如何看待这种方法呢？
编辑：我应该提到这是针对所谓的业务Web API的，而不是针对浏览器的。
202。实际上，恕我直言很少使用它，因为很少有Web开发人员关心适当的状态代码，因为他们更习惯于浏览器/用户-代理交互，在这种情况下，a202不会给他们任何可见的线索（给他们a200，他们会很高兴。 ..）。