用于REST的HTTP MODIFY动词?

Ste*_*ini 13 rest http http-headers

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

我相信这暗示了HTTP1.1中缺少动词:类似于MODIFY或PATCH.甚至WebDAV都没有这个动词(它有PROPPATCH,其概念类似,但不适用于资源).

对于真实世界的REST,当前的HTTP 1.1动词集是不是太有限了?

编辑:我在IETF找到了关于PATCH动词的提议

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

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

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

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

编辑: 截至2010年3月,RFC 5789存在(HTTP的PATCH方法).

DSO*_*DSO 8

您可以将资源划分为可单独更新的子资源.

例如,您有一个表示用户帐户信息的/ user资源,您可以创建/ user/email子资源,然后在其上执行PUT以仅更新电子邮件.


Avi*_*lax 7

您可以使用POST进行部分更新.它并不理想,但它相当RESTful.


Gan*_*alf 2

有充分的理由没有这样的动词来做到这一点。这几乎是不可能管理的。想象一下数百个客户端以这种方式修改相同的资源,您如何知道您的修改最终在哪里?如果顺序很重要,并且您的“补丁”实际上是在另一个“补丁”之后添加的,而现在您要添加的内容实际上不是添加的内容,该怎么办?将 PUT 与 ETag 标头一起使用是一种更明智的修改资源的方法,而不是尝试将一些具有未知结果的新动词拼凑在一起。为了获得可重复的结果,必须实际获取资源只是一个很小的代价。

  • 好吧,只有当 ETag 与以前相同时才可以执行 PATCH。乐观锁。这样就可以保证您的修改适用于您所引用的副本。我同意这个解决方案还存在其他问题。我接受你的回答,因为你确实有一个很好的观点。 (3认同)