异步 REST 操作的处理

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