持久的 RESTful 交互 [英] Long-lived RESTful interactions

问题描述

目前我们的团队正在进行讨论，我对其他观点很感兴趣.假设我们有一个 RESTful Web 服务，其作用是通过应用各种分析算法和服务来注释文档.明确的基本交互:我们有一个资源，即文档集合；客户端 POST 一个新文档到集合，获取新文档的 URI，然后可以 GET 那个 docURI 来获取文档或者 GET {docURI}/metadata查看一般元数据，{docURI}/ne 用于命名实体等.问题是某些分析可能需要很长时间才能完成.假设客户端在分析完成之前获取元数据 URI，因为它希望能够在 UI 中显示部分或增量结果.将来重复 GET 可能会产生更多结果.

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:

• 保持 HTTP 连接打开直到所有分析完成(其中似乎不可扩展)
• 使用content-length 和 accept-range标题以获取增量内容(但我们不知道提前多久最终内容将是)
• 提供每个资源的 Atom 提要客户端订阅更新事件而不是简单的 GET资源(似乎过度如果有许多活动文档，则复杂且可能需要资源)
• 只需 GET 返回任何当时可用的东西(但它仍然留下客户的问题知道我们什么时候终于完成了).

• 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].

对于在 RESTful 架构中处理长期或异步交互的替代方法有任何意见或建议吗?

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

伊恩

推荐答案

为每个资源提供一个 Atom 提要，以便客户端订阅更新事件而不是简单地获取资源(如果有许多活动文档，这似乎过于复杂并且可能资源匮乏)

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)

您是否考虑过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屋！