如何提交 RESTful 部分更新？
“RESTful Web Services”的作者 Sam Ruby 似乎反对使用 HTTP PUT 进行部分更新：http://intertwingly.net/blog/2008/02/15/Embrace-Extend-then-Innovate
不清楚的是部分更新应该如何 /em> 发生。 正如我在他的博客底部附近评论的那样，目前尚不清楚使用 HTTP PATCH 是否比使用针对 HTTP PUT 的“补丁文档”更好。
值得注意的是，尽管 Sam 反对滥用 HTTP PUT，但他似乎也不提倡使用 HTTP PATCH。
应如何提交 RESTful 部分更新？
Sam Ruby, author of "RESTful Web Services" seems to come out against the use of HTTP PUT for partial updates: http://intertwingly.net/blog/2008/02/15/Embrace-Extend-then-Innovate
What isn't clear is how partial updates should take place. As I commented near the bottom of his blog, it isn't clear how using HTTP PATCH is any better than using a "patch document" against HTTP PUT.
It is worth noting that although Sam comes out against misusing HTTP PUT he doesn't seem to advocate the use of HTTP PATCH either.
How should one submit RESTful partial updates?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正如您从您引用的博客文章中的评论中看到的那样，没有达成一致的方法来进行部分更新。 如果萨姆·鲁比、乔·格雷加里奥、马克·诺丁汉、马克·皮尔格里姆、比尔·德赫拉等重量级人物不能达成协议，我们还有什么希望。
就我而言，我不会太担心。 创建适合您的部分更新媒体类型，使用 PATCH 来表明您的意图，当最终就通用媒体类型达成一致时，更改您的服务器以接受这两种格式。
值得庆幸的是，如果你的 REST api 犯下的最严重的错误是滥用 PUT/PATCH，那么你就做得很好了。
As you can see from the comments in the blog post you referenced there is no agreed upon way to do partial updates. If heavyweights like Sam Ruby, Joe Gregario, Mark Nottingham, Mark Pilgrim, Bill de hÓra, etc cannot come to an agreement, what hope do we have.
As far as I am concerned, I wouldn't worry too much. Create a partial update media type that works for you, use PATCH to indicate your intent and when agreement is finally reached on a general purpose media type, change your server to accept both formats.
Be thankful that if the worst sin your REST api commits is abusing PUT/PATCH then you are doing pretty well.
现在是 2013 年 - 您应该使用 PATCH 进行部分更新 - 要么使用 json-patch (参见 https ://www.rfc-editor.org/rfc/rfc6902 或 http://www.mnot.net/blog/2012/09/05/patch）或 xml-patch 文档（参见 https://www.rfc-editor.org/rfc/rfc7351）。 但在我看来，json-patch 最适合您的业务数据类型。
带有 JSON/XML 补丁文档的 PATCH 对于部分更新具有非常严格的前向语义。 如果您开始使用 POST，并修改原始文档的副本，对于部分更新，您很快就会遇到问题，您希望缺失值（或者更确切地说，空值）来表示“忽略此属性”或“将此属性设置为空值” - 这会导致黑客解决方案陷入困境，最终会导致您自己的补丁格式。
您可以在这里找到更深入的答案： http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html。
更新：这是 RPC 吗？
那么，如果您将 RPC 定义为向服务器发送命令，那么任何和所有 HTTP 操作都是 RPC 调用 - 无论您获取资源、放置新表示还是再次删除它 -它们中的每一个都包含发送命令（动词）GET/PUT/DELETE 等以及可选的有效负载。 碰巧 HTTP 工作组（或者无论是谁）引入了一个新的动词 PATCH，它允许客户端对资源进行部分更新。
如果除了将完整表示发送到服务器之外的任何其他方式都被视为 RPC 风格，那么根据定义，部分更新不能是 RESTful。 人们可以选择持有这种观点，但网络基础设施背后的人们却有不同的说法——因此为此目的定义了一个新的动词。
RPC 更多的是通过 HTTP 以一种对 Web 上的中介不可见的方式进行隧道方法调用 - 例如使用 SOAP 来包装方法名称和参数。 这些操作是“不可见的”，因为没有标准定义有效负载内的方法和参数。
将此与媒体类型为 application/json-patch 的 PATCH 进行比较 - 操作的意图对于网络上的任何中介都清晰可见，因为动词 PATCH 具有明确定义的含义，并且有效负载以另一种明确定义的公共可用格式进行编码由网络通用权威机构 (IETF) 制定。 最终结果是每个人都完全可见，并且没有特定于应用程序的秘密语义。
REST 还涉及“偶然重用”，这正是 PATCH 与 application/json-patch 的含义 - 重用现有标准，而不是发明或多或少相同的应用程序特定协议。
It is now year 2013 - you should use PATCH for partial updates - either using json-patch (see https://www.rfc-editor.org/rfc/rfc6902 or http://www.mnot.net/blog/2012/09/05/patch) or the xml-patch documents (see https://www.rfc-editor.org/rfc/rfc7351). In my opinion though, json-patch is the best fit for your kind of business data.
PATCH with JSON/XML patch documents has very strait forward semantics for partial updates. If you start using POST, with modified copies of the original document, for partial updates you soon run into problems where you want missing values (or, rather, null values) to represent either "ignore this property" or "set this property to the empty value" - and that leads down a rabbit hole of hacked solutions that in the end will result in your own kind of patch format.
You can find a more in-depth answer here: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html.
Update: Is this RPC?
Well, if you define RPC as sending commands to a server then any and all HTTP operations are RPC calls - whether you GET a resource, PUT a new representation or DELETE it again - each of them consist of a sending a command (verb) GET/PUT/DELETE etc. and a optional payload. It just happens that the HTTP working group (or who ever it is) has introduced a new verb PATCH which allows clients to do partial updates to a resource.
If anything else than sending the complete representation to the server is considered RPC style, then, by definition, partial updates cannot be RESTful. One can choose to have this point of view, but the people behind the web infrastructure says differently - and has thus defined a new verb for this purpose.
RPC is more about tunnelling method calls through HTTP in a way that is invisible to intermediaries on the web - for instance using SOAP to wrap method names and parameters. These operations are "invisible" since there are no standards defining the methods and parameters inside the payload.
Compare this to PATCH with the media type application/json-patch - the intention of the operation is clearly visible to any intermediary on the web since the verb PATCH has a well defined meaning and the payload is encoded in another well defined public available format owned by common authority on the web (IETF). The net result is full visibility for everybody and no application specific secret semantics.
REST is also about "serendipitous reuse" which is exactly what PATCH with application/json-patch is - reusing an existing standard instead of inventing application specific protocols that do more or less the same.
您可以为部分资源提供自己的 URI，而不是自制部分更新媒体类型并使用非标准 PATCH 方法。
Instead of home-brewing a partial update media type and using the yet-non-standard PATCH method, you could give parts of your resources their own URI.
HTTP PATCH 现在有一个 RFC - HTTP PATCH RFC
HTTP PATCH now has an RFC - HTTP PATCH RFC