合并,替换,还是补丁:Astoria 如何应对变化的数据

  • Jonathan Allen
  • 黄璜

2008 年 6 月 25 日

话题:SOA.NETRESTDevOps语言 & 开发架构

在使用 REST 时,当你执行一个 PUT 操作来更新已有的数据时会发生什么事?Astoria 团队提出了这个问题,并给出了他们的答案。

当一个基于 Astoria 协议的 web 服务收到一个 PUT 操作的请求,它有两种方式可以来处理这个更新:或者替换掉原有的数据,或者将新的值与原来的数据进行合并。为了保持与 AtomPub 协议的兼容性,微软决定 PUT 应该对应于替换操作。

这显然使得如何表示合并操作成为了一个问题。可用的选项包括引入一个新的动词,MERGE,或者是一个新的定制报头。Pablo Castro写到,

虽然我们并不因引入了一个 HTTP 新方法很兴奋,但用额外的报头重载 PUT 却是非常成问题的。别的不说,假如一个服务器因不能通过报头来支持“合并”操作而将其当作了常规的“替换”请求并执行了这一操作,这绝对不是客户想看到的。同样,其它的东西也受到影响。例如,一个服务器获得了一个真正的 MERGE 请求但并不能处理它,它可以返回 405-不支持的方法。

他们所考虑的另一个意见是 PATCH 操作。遗憾的是,在微软的代码冻结的时候,该规范还未能最终确定下来。这使微软陷入了进退维谷的境地,要么冒着与最终规范不兼容的风险使用 PATCH,要么使用可能会过时的 MERGE。鉴于第一个选择有可能损害客户或者造成与规范的不兼容,他们决定使用 MERGE。

因为我们的话题是在客户端,需要注意的是.NET 客户端默认就是合并语义。作出这样的选择是因为一个.NET 客户端可能并不能知道服务器上所有的字段,而服务器无法区分哪些字段是故意空缺的和本来就未知。

AJAX 客户端同样默认的是合并的语义。像.NET 客户端一样,它们也有一个可选的参数来表明想要选择的是替换的语义。

查看英文原文Merge, Replace, or Patch: How Astoria Handles Changing Data
SOA.NETRESTDevOps语言 & 开发架构