目前我们的团队正在进行讨论,我对其他观点感兴趣。假设我们有一个 RESTful Web 服务,其作用是通过应用各种分析算法和服务来注释文档。基本交互清晰:我们有一个资源,即文档集合;客户端将新文档 POST 到集合中,获取新文档的 URI,然后可以获取该文档docURI
取回文档或 GET{docURI}/metadata
查看一般元数据,{docURI}/ne
问题是某些分析可能需要很长时间才能完成。假设客户端在分析完成之前获取元数据 URI,因为它希望能够在 UI 中显示部分或增量结果。将来重复 GET 可能会产生更多结果。
我们讨论的解决方案包括:
- 保持 HTTP 连接打开
直到完成所有分析(其中
似乎不可扩展)
- using
content-length
and accept-range
标题来获取增量内容(但是
我们事先不知道需要多长时间
最终内容将是)
- 提供
每个资源都有一个 Atom feed,因此
客户端订阅更新
事件而不是简单的获取
资源(似乎过度
如果有很多活动文档,则很复杂并且可能会占用资源)
- 只是有 GET 返回
任何当时可用的东西(但它仍然
把问题留给客户
知道我们什么时候终于完成)[编辑以删除以下评论中对幂等性的引用].
对于在 RESTful 架构中处理长期或异步交互的替代方法有什么意见或建议吗?
Ian
我将通过以下方式实现它:
1)客户端请求元数据
2) 服务器返回实际数据(如果已经可用)或 NotReady 标记
3)客户端询问服务器数据何时可用(此步骤可以与上一步合并)
4)服务器返回时间间隔(可能有一些关于执行作业总数的启发式等)
5) 客户端等待指定的时间并转到步骤1
这样您就可以尽快向客户提供数据。您可以通过调整步骤 4 返回的延迟间隔来调整服务器负载)
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)