在使用 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
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论