我有一组资源,其表示被懒惰地创建.构建这些表示的计算可能需要几毫秒到几个小时,具体取决于服务器负载,特定资源和月亮的相位.
收到的第一个GET请求开始在服务器上进行计算.如果计算在几秒钟内完成,则返回计算的表示.否则,返回202"已接受"状态代码,客户端必须轮询资源,直到最终表示可用.
出现这种情况的原因如下:如果结果在几秒钟内可用,则需要尽快检索; 否则,当它变得可用时并不重要.
由于内存有限和请求量很大,NIO和长轮询都不是一个选项(即我无法保持足够的连接打开,甚至我甚至无法将所有请求都放在内存中;一次"几秒钟"已经过去了,我坚持多余的要求).同样,客户端限制使得它们无法处理完成回调.最后,请注意我对创建一个POST的"工厂"资源不感兴趣,因为额外的往返意味着我们的分段实时约束超出了预期(此外,它是额外的复杂性;此外,这是一种资源,受益于缓存).
我想在返回202"接受"状态代码以响应GET请求方面存在一些争议,因为我在实践中从未见过它,并且它最直观的用法是回应不安全的方法,但我从来没有发现任何特别令人沮丧的事情.而且,我不保持安全和幂等性吗？
那么,人们对这种方法有何看法？
编辑:我应该提到这是一个所谓的商业网络API - 不适用于浏览器.
我需要实现一个Java REST Web服务(我们使用Jersey框架),它基本上都可以
一个.在返回响应之前阻止等待某个事件(或事件的轮询).提供某种aysnc行为以在处理请求时通知客户端.
我正在考虑返回一个transationID,并且有一个/ status端点,客户端应该轮询该端点以确定是否处理了请求并获得特定结果.
有任何想法吗？