用于REST的HTTP MODIFY动词？ [英] HTTP MODIFY verb for REST?

问题描述

据我所知，没有RESTful方法可以对资源进行修改。为了做到这一点，你必须将资源作为一个整体，覆盖以前的表示。我认为这是问题的根源，特别是当资源具有大量表示时。

As far as I see, there's no RESTful way to apply a modification to a resource. In order to do it, you have to PUT the resource as a whole, overwriting the previous representation. I think this is source of problems, in particular when the resource has a large representation.

我相信这暗示了HTTP1.1中缺少动词：类似于MODIFY或PATCH。甚至连WebDAV都没有这个动词（它有PROPPATCH，其概念类似，但不适用于资源）。

I believe this hints at the lack of a verb in HTTP1.1 : something like MODIFY, or PATCH. Not even WebDAV has this verb (it has PROPPATCH, whose concept is similar, but not for the resources).

当前的HTTP 1.1动词集是不是太有限了对于现实世界的RESTing？

Isn't the current HTTP 1.1 set of verbs too limited for real world RESTing ?

编辑：我在IETF找到了关于PATCH动词的提案

Edit: I found a proposal at IETF about the PATCH verb

http://tools.ietf.org/html/draft -dusseault-http-patch-15

此规范定义了新的
HTTP / 1.1 [RFC2616]方法PATCH
，用于对资源进行部分
修改。

This specification defines the new HTTP/1.1 [RFC2616] method PATCH that is used to apply partial modifications to a resource.

需要一种新方法来提高互操作性并防止
错误。 PUT方法已经定义为
，用一个完整的新主体覆盖资源
，并且不能重新使用
来进行部分更改。
否则，代理和缓存甚至
客户端和服务器可能会因
操作的结果而混淆
。在
之前的HTTP规范中提到了PATCH，但没有完全定义
。

A new method is necessary to improve interoperability and prevent errors. The PUT method is already defined to overwrite a resource with a complete new body, and can not be reused to do partial changes. Otherwise, proxies and caches and even clients and servers may get confused as to the result of the operation. PATCH was mentioned in earlier HTTP specifications, but not completely defined.

据我所知，这种动词的唯一问题是缺乏幂等性。

As far as I see, the only problem of such a verb is lack of idempotency.

编辑：截至2010年3月，RFC 5789存在（ HTTP的PATCH方法）。

As of March 2010, RFC 5789 exists (PATCH Method for HTTP).

推荐答案

有充分的理由没有这样的动词来做这件事。管理几乎是不可能的。想想100个客户以这种方式修改相同的资源，你怎么知道你的修改到底在哪里？如果订单很重要，你的补丁实际上是在另一个补丁后添加的，现在你要添加的内容实际上不是添加的内容。使用带有ETag标头的PUT是一种更加理智的方法来修改资源，然后尝试将一些具有未知结果的新动词混合在一起。实际获得资源是一个很小的代价，可以为可重复的结果付出代价。

There is good reason there is no such verb to do this. It's almost impossible to manage. Think of 100's of clients modifying the same resource in this way, how do you know where your modification ends up? What if order matters, and your "patch" is actually added after another "patch" and now what you meant to add i actually not what was added. Using PUT with ETag headers is a much more sane approach to modifying a resource then trying to hobble together some new verb with unknown results. Having to actually GET the resource is a small price to pay for repeatable results.

这篇关于用于REST的HTTP MODIFY动词？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！