REST 的 HTTP MODIFY 动词？答案

【问题标题】：HTTP MODIFY verb for REST?REST 的 HTTP MODIFY 动词？
【发布时间】：2010-12-12 22:08:55
【问题描述】：

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

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

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

编辑：我在 IETF 发现了一个关于 PATCH 动词的提案

https://datatracker.ietf.org/doc/html/draft-dusseault-http-patch-15

本规范定义了新的 HTTP/1.1 [RFC2616] 方法补丁用于应用部分修改资源。

需要一种新方法提高互操作性并防止错误。 PUT 方法已经定义为覆盖资源拥有一个全新的身体，并不能被重用做部分改变。否则，代理和缓存甚至客户端和服务器可能会得到对结果感到困惑手术。 PATCH 在早期的 HTTP 规范，但不是完全定义。

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

编辑：截至 2010 年 3 月，RFC 5789 存在 (PATCH Method for HTTP)。

【问题讨论】：

我认为 PATCH 动词的真正问题是没有人完全确定在应用更新时使用什么媒体类型。如果您的表示是基于 XML 的，情况尤其如此。显然 XML 很难定义差异格式。
与此同时，RFC 6902 定义了application/json-patch+json。有关详细信息，请参阅jsonpatch.com。

标签： http rest http-headers

【解决方案1】：

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

例如您有一个代表用户帐户信息的 /user 资源，您可以创建一个 /user/email 子资源，然后对其执行 PUT 以仅更新电子邮件。 p>

【讨论】：

这种情况下，请求应该返回什么？
我认为在某些情况下这个解决方案比“PATCH 解决方案”更好。

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

【讨论】：

好吧，只有当 ETag 和以前一样，你才能做 PATCH。乐观锁定。这样可以保证您的修改适用于您引用的副本。我同意这个解决方案还有其他问题。我接受你的回答，因为你的观点确实很好。

【解决方案4】：

我希望有标准化和受支持的动词，例如...

FIND、SEARCH 或 QUERY - 很明显请求不是针对 a 资源，而是针对其他资源的位置。也许只有有限的用处。
MOVE、COPY、LINK - 非常方便，它们的行为类似于命令行工具。
DISCOVER、MAP、INDEX 或 SITEMAP - 这样您就可以获得资源布局，在概念上类似于 wsdl 文件或 xmlrpc 的 system.listMethods。
BEGIN、ACQUIRE 或 LOCK，以及 COMMIT、END、DONE 或 RELEASE - 明确您何时开始和结束事务，或使用中间资源。
修改、更新、补丁 - 因为我们都想要它

【讨论】：

REST 人（菲尔丁）并不特别喜欢事务。和往常一样，他没有解释在他看来什么是 RESTful 方法。然而，这个问题远非微不足道，锁定也不是解决办法。
在 FIND/SEARCH/QUERY 上，嗯……网络的想法是你对名词执行动词，这些名词地址资源。 FIND 不是一个动词，您可以将其应用于资源。它是您应用于服务以查找资源的动词。所以它不太适合 REST。
您可以通过使事务本身成为资源来以 REST 方式实现事务。 POST 或 PUT 创建新的事务资源，GET 获取当前事务状态，POST 更新、提交或回滚事务。
你可以添加任何你想要的方法。但是，您会变得越来越少 RESTful，而更多地使用 RPC over HTTP，这很好，只要您了解使用 REST 与 RPC 样式的含义。
嗯，查找，搜索，查询...我更喜欢 DISCOVER 或 LOOKUP，或者 HUNT 怎么样？如果没有找到结果，它是否应该返回错误？我可以只返回位置，还是也可以返回一些摘要数据？ ... 是的，我在开玩笑。一旦你尝试引入一个新动词，你就会引入一大堆需要得到很多人共识的问题。坚持使用 GET，让媒体类型告诉您收到的是列表还是单个项目。