我有一组资源,其表示是延迟创建的。构建这些表示的计算可能需要几毫秒到几小时不等,具体取决于服务器负载、特定资源和月相。
为资源收到的第一个 GET 请求启动服务器上的计算。如果计算在几秒钟内完成,则返回计算的表示。否则,将返回 202“已接受”状态代码,并且客户端必须轮询资源,直到最终表示可用。
这种行为的原因如下:如果结果在几秒钟内可用,则需要尽快检索;否则,何时可用并不重要。
由于内存有限和请求数量庞大,NIO 和长轮询都不是一个选项(即,我无法保持几乎足够的连接打开,甚至无法将所有请求都放入内存;一旦“几秒钟”已经过去了,我坚持多余的请求)。同样,客户端的限制使得它们无法处理完成回调。最后,请注意,我对创建一个 POST 到的“工厂”资源不感兴趣,因为额外的往返意味着我们超出了预期的分段实时约束(此外,它是额外的复杂性;而且,这是一个资源受益于缓存)。
我想在响应 GET 请求时返回 202“已接受”状态代码存在一些争议,因为我在实践中从未见过它,它最直观的用途是响应不安全的方法,但我从来没有发现任何特别令人沮丧的东西。此外,我不是同时保持安全性和幂等性吗?
那么,人们如何看待这种方法呢?
编辑:我应该提到这是针对所谓的业务 Web API 的——而不是针对浏览器的。