英文原文：
Best Practice For The Use of PATCH in RESTful API Design
这个话题独自处置.之前我写过一篇情况布景基于SCIM的 文章， PATCH是最新的 HTTP verb被引荐用于 已知资本实行部分更新，比拟而言， PUT 就比拟小题大做。 PUT办法用来创立一个URI已知的资本，或对已知资本实行完整交换.
所以PATCH的呈现，毫无疑问是很受欢送的局势开展，但一个火烧眉毛的问题是形成以后web根底设备. 并非一切的根底设备支撑 PATCH.在防火墙中是可疑数据， 在代办署理中是可能会破坏或删除可疑音讯，并且并非一切的webServer都能处置它，等等。见鬼，即便是最新的 5标准也没有供给 PUT 和DELETE 动词, 所以如今想请求供给PATCH 支撑有点艰苦.
但是,我并非太担忧这些问题，由于工夫是最巨大的根底设备安排者. (另外，在这方面我没能供给其他协助.)
我看到更大的问题是，我们作为api设计者其实不真正晓得怎么运用 PATCH.另外，除处置运用PATCH的部分更新外，没有其他相干指点 .每一个人都晓得，我们需求更纤细的把持更新的资本，但这需求愈加精密的具体标准,。我们基本没有这方面内容.
好了，我们 如今有了。请记着，你是在这里第一次浏览到相干内容:-).
起首,我们运用JSON 模子资本，由于json非常盛行，大大多数开发者都了解它（是的，我晓得。我是一个 SOFEA 作者,但我不爱好xml.)
其它翻译版本 (2)
加载中
你或许晓得JSON家族实践上包括两兄弟，一个好的和一个罪恶的。Abel和Cain、Thor和Loki、Edwin Booth和John Wilkes Booth，随意选吧。
我称它们为JSON the Argonaut和JSON Voorhees（约十三5）。
JSON Argonaut是好的阿谁。当看扮演时它给家里的每一个人都买了票。
JSON Voorhees是坏的阿谁。他为本人买了一张票，并让他的孩子从转门滑下逃跑。
你或许想晓得为何很难在扮演时找到坐位。
你不晓得我在说甚么，有么？
看一下
JSON的网站：
JSON有两个构造：
- 键/值对的聚集。在其他言语可能称之为工具，记载，构造，字典，哈希表，列表，或许联系关系数组。
- 一个有序的值列表。在其他言语可能称之为数组，向量，列表，或序列。
翻开看了吧？第一个构造描绘了JSON the Argonaut，他确保家里的每一个成员都有票（标签或要害字）。第二构造描绘了JSON Voorhees，他只需本人的一张票（标签或要害字）。我们需求做的第一件事是修复JSON Voorhees。我的意思是说，让他为他的孩子们买票。
JSON Voorhees家看起来就像如许，就一张票：
这是我们盼望的模样，当他为家里每一个人买票时他需求：
你看，每一个值一个标签。
换个说法，当处置JSON工具时，把一切数组转换成字典。
[假如条目标次序很主要，当把它酿成字典时不想失去这个信息，生成序列中的键，仅仅存眷键间能否有足够的“空地”以便厥后有需求时拔出。我以为像B-Tree那样的算法将很有效。]
当我们POST一个包括数组的资本到Server，Server应当把它们转换成字典，前往给我们资本的最新表现。一切生成的键应当运用新的表征。这是有首字母G的长度，由于如今忽然，PATCH的任务愈加容易了。
[为何我们不间接运用地位索引，比方email-addrs[i]？思索一下当一个客户端履行一个GET而且需求删除email-addrs[1]时会发作甚么。于此同时，别的一个客户端也删除email-addrs[1]，这将招致email-addrs[2]酿成了新的email-addrs[1]。然后第一个客户端就终极删除过错的属性。固然，你可以在更新之前反省Etags和if-not-modified headers从而防止发作这类问题，可是在高并发性的状况下，这将会招致大量的失败更新，而这一切本可以经过运用独一且波动的标识符来防止。]
如今，不管属性有多庞杂或许嵌套的条理有多深，在资本外部PATCH对每一个属性都有独一的句柄与之绝对应。每一个值都有一个独一的键，其可以表现为
first.second.third.fourth.fifth
假如相对顶层资本的URI低五个层级。
如今我们可使用在PATCH之前我们曾经熟知的
REST
观点。那些
REST中运用的
粗粒度动词如今异样可以用来操作部分资本。
POST添加一个新的属性到聚集中
PUT代替一个属性的值
DELETE使一个属性没法运用（不是删除它的身材）
比拟REST中的URI，我们在资本中为属性指定键，用我们方才演示的小数点分开符号。
这里只要一个小细节。实践上是两个。
其它翻译版本 (1)
加载中
1.PATCH将是一个操作容器而不是操作自身。这意味着我们要在资本的分歧部分嵌套其他举措。没有甚么可以禁止我们将行添加、修正和删除等操作绑定到高层URI和PATCH恳求目的等所代表的资本部分等营业上。现实上，这也许就是我们寻求的那种优雅。可是我们不想让这些嵌套操作和使用到资本上的HTTP粒度操作间有任何混杂，所以我们应当寻觅合适的POST、PUT及DELETE等动词在PATCH内运用。
2.当我们考虑这个问题时，HTTP中PUT这个动词意思有点不明晰（最少对我来讲）。我们是计划交换掉已有资本呢，仍是计划用我们本人选择的URL（而不是Server决议的URI）从头创立一个资本呢？在这两种状况下怎样指犯错误呢（由于它们是完整相反的前提）？我们可能需求分拆PUT来反应这些独自的“发明”或“更新”的语义，进一步的办法是定义第三品种型来表现“创立或更新”的状况，这也是很有可能需求的。固然有点曾经有了，我们可能想减少POST的范畴让它只意味着“添加到聚集”，由于POST如今在REST里是一个应有尽有的号令，其他动词则没有这类使用。
将这两个状况记在心里，让我们看看在一个PATCH恳求中我们有甚么新动词可以用做嵌套操作。
- INCLUDE（相当于POST）：将给定的属性值添加到聚集并前往为它生成的独一要害字。
- PLACE (相当于PUT的一种方式)：添加给定属性的键-值对到键的当地地位。（假如曾经有该键的属性，前往一个过错形态。）
- REPLACE (相当于PUT的另外一种方式)： 将给定键的值用新值交换（假如没有该键，前往一个过错形态。）
- FORCE (相当于PUT的第三种方式)：这意味着PLACE或REPLACE。（这个操作后，指定的键与给定的值相连，不论键能否存在）
- RETIRE (相当于DELETE)：删除，禁用或以其他方法使给定的键属性没法运用。
- AMEND (相当于PATCH)：（这个动词被列出是思索完好性。我们不需求嵌套的PATCH，由于PATCH级联树的每级。）
本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。
2KB翻译任务按照
CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
