异步 REST 操作的处理

阅读数:2574 2009 年 7 月 9 日

话题:SOAREST架构

Tim Bray 在他的新博文Slow REST中尝试回答以下问题:

在 RESTful 的环境中,如何处理(POST、PUT、DELETE)等操作对资源状态的改变。这些操作存在延时,有时行为也不可预测。

Tim 为我们描述了解决这种问题三种不同方法,他们出自Project Kenai的正式报告《处理异步操作请求》的一部分,描述如下:

  • 基于资源的方法
    新的“Status”资源模型……包含以下属性域:
    • “uri”:客户端进行轮询“完成状态”的 GET 操作所使用的 URI。每一个被接受的异步操作将收到一个唯一的状态 URI,这样就可以对多个操作同时进行初始化和跟踪。
    • “status”:它是一个整型数值,用于描述完成状态(0= 成功,非 0= 错误码),该状态码只有在“progress”返回 100 时才返回。
    • “message”:完成状态消息描述,只有在“progress”返回 100 时才返回
    • “progress”:指示操作的进度,整型数值,当操作完成执行时,不论是成功还是失败,都返回 100。
    上述资源对象可以这样使用:
    对于任何 PUT/POST/DELETE 操作,返回“202 In progress”,并返回“Status”资源,……目的是为实现者提供低成本的用于轮询的钩子(hook)。
  • Comet 风格的实现——为长运行的请求保持 HTTP 通道的开放。
    • 初始响应消息必须包含 202 的 HTTP 状态码(“Accepted”)……以及包含本次操作的初始 Status 资源的消息实体。在 Status 资源中一定要包含“uri”和“progress”两个属性,其中“progress” 域必须是 0,用于指定操作已经开始。
    • 初始响应消息的 URI 值必须包含对应着 GET 操作的新 Status 资源。典型地,“progress” 域的数值会向 100 增长,但是不到操作结束一定不能被设成 100。
    • 当操作结束时(成功或失败),状态资源的“最终”形式必须返回,其中“progress”域被设置成 100,“status”域被设置成 0(对于成功完成)或者非 0 的数值(对于失败的完成)。
  • “Web hooks”型:使用两个独立的“one-way”调用,一个用于启动长运行的操作,另一个用于在操作完成时通知请求者。
    • 请求操作的入站消息可能包含一个“webhook”域,如果客户端期待回调,该域的值是一个 URI;如果这个域不存在,则说明客户端不需要回调。
    • 操作完成时(成功或失败),服务器将向 webhook URI 发出一个 POST 请求,附带……包含 该操作最终状态资源的消息
    • 客户端通过对完成报告与初始 Status 响应中“URI”域的比较,找到的原始的请求,也可以通 过为每次异步请求提供一个唯一的 webhook URI 来将关联响应和请

Tim 在结束博文的结尾向大家征求意见:

……是否整个“Slow REST”能够作为一个模式?今后当人们考虑标准的实现方法时,是否会经常想起它。

Tim 的博文引起了若干回复,其中比较有意思的一条回复来自 William Vambenepe,他将 Tim 博文中提出的问题和解决方法同 WS* 标准(特别是 WSRF 和 WS-Notifications)中的问题和解决方法做了一个比较。William 认为:

WSRF 并没有覆盖博文中介绍的场景,但是在 WS-ResourceLifetime 和 WS-Notification 中我们依稀可见一些相似的场景(也许下次你就会碰到)。如果加入 WS-MakeConnection (WS- RX 的一部分),你的“web hooks”的想法可能会更切合实际……我常常有一种直觉:“REST”和“WS-*” 应该走得更近。

尽管在 REST 和 WS* 存在着很多差异(有些是实际存在的,有些是信仰上的),两个阵营都致力于解决实际生活中存在的问题,也必然会碰到相同的挑战。相互借鉴对方的实现和经验必然会互助互惠。

查看英文原文Handling Asynchronous REST Operations