长寿命RESTful交互 [英] Long-lived RESTful interactions

问题描述

我们有一个讨论，此刻在我的团队回事，我很想在其他意见。假设我们有其作用是通过应用各种分析算法和服务注释文档RESTful Web服务。在明确基本的互动：我们有一个资源是文档集合;客户端发布一个新的文档的收集，回来的新文档的URI，那么可以得到 docURI 来获取文档背面或GET {} docURI /元来看看一般的元数据， {} docURI / NE 命名实体等的问题是，一些分析可能需要很长的时间才能完成。假设客户端获取元数据URI之前分析完成，因为它要能够显示在UI部分或增量的结果。在未来重复GET可能会产生更多的结果。

我们已经讨论解决方案包括：

• 保持HTTP连接打开
  直到所有的分析都做了（这
  似乎没有可扩展）


• 使用
  内容长度和接受范围
  头获取增量的内容（但
  我们事先不知道过了多久
  最终的内容将是）


• 提供
  Atom提要每个资源等等
  客户端订阅更新
  事件，而不是仅仅让
  资源（似乎过于
  复杂的和可能的资源饿了，如果有很多的活动文档）


• 只是有获取返回
  任何可用的时间（但它仍然
  离开客户端的问题
  知道什么时候我们终于完成）的 的

任何意见或建议的替代方法来处理一个RESTful架构长寿命或异步交互？

伊恩

解决方案

  

提供每个资源的Atom提要，所以客户端订阅更新事件，而不是简单地获取该资源（似乎过于复杂，如果有很多活动文档可能耗资源）

你有没有考虑 SUP ？

如果投票是一种选择，为什么用料费心呢？为什么不只是有客户端轮询资源本身？

您能否通过包括估计的时间分析完成削减不必要的投票？

We have a discussion going on in my team at the moment, and I'd be interested in other views. Suppose we have a RESTful web service whose role is to annotate documents by applying a variety of analysis algorithms and services. The basic interaction in clear: we have a resource which is the document collection; the client POSTs a new document to the collection, gets back the URI of the new document, then can GET that docURI to get the document back or GET {docURI}/metadata to see the general metadata, {docURI}/ne for named entities, etc. The problem is that some of the analyses may take a long time to complete. Suppose the client GETs the metadata URI before the analysis is complete, because it wants to be able to show partial or incremental results in the UI. Repeating the GET in future may yield more results.

Solutions we've discussed include:

• keeping the HTTP connection open until all analyses are done (which doesn't seem scalable)
• using content-length and accept-range headers to get incremental content (but we don't know in advance how long the final content will be)
• providing an Atom feed for each resource so the client subscribes to update events rather than simply GETting the resource (seems overly complicated and possibly resource hungry if there are many active documents)
• just having GET return whatever is available at the time (but it still leaves the problem of the client knowing when we're finally done) [edited to remove reference to idempotency following comments].

Any opinions, or suggestions for alternative ways to handle long-lived or asynchronous interactions in a RESTful architecture?

Ian

解决方案

providing an Atom feed for each resource so the client subscribes to update events rather than simply GETting the resource (seems overly complicated and possibly resource hungry if there are many active documents)

Have you considered SUP?

If polling is an option, why bother with a feed? Why not just have the clients poll the resource itself?

Could you cut down on unnecessary polling by including an estimated time for completion of the analyses?

这篇关于长寿命RESTful交互的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！