资源 ID 是否应该放在 PUT 和 PATCH 请求的 URL 中？答案

【问题标题】：Should the resource ID be put in URL of PUT and PATCH requests?资源 ID 是否应该放在 PUT 和 PATCH 请求的 URL 中？
【发布时间】：2020-04-22 19:41:52
【问题描述】：

PUT 和 PATCH 的 URL 应该包含 ID 还是可以放在正文中？

PUT /person/UUID {"name": "Jimmy"}

或

PUT /person/{"UUID":1, "name": "Jimmy"}

（PATCH 也一样） ?

【问题讨论】：

标签： rest patch put

【解决方案1】：

PUT 被定义为 将在 URI 位置找到的当前文档替换为有效负载中提供的文档 向 /person 发送 PUT 请求可能会导致删除由该特定端点管理的任何人，以防该 URI 表示人员集合。

正如this post 中提到的，如果这是一个通用容器，可能会使用没有一些特殊实体标识符的 URI。考虑一个剪贴板，您可以将一些数据复制到其中，以便稍后检索它以将其粘贴到其他地方。在这种情况下，标识符由 URI 本身隐式给出，因为毕竟 URI 代表 唯一资源标识符

请注意，URI 作为一个整体来标识资源，并不一定意味着某种形式的父子结构。客户端尤其不应该尝试从 URI 中提取知识。

关于PATCH，这取决于。通常应该使用一种用于修补的媒体类型，例如JSON Patch 或JSON Merge Patch。

前一种表示法定义了某些字段，这些字段声明应添加、删除或替换为给定值的字段，如下所示：

   PATCH /my/data HTTP/1.1
   Host: example.org
   Content-Length: 326
   Content-Type: application/json-patch+json
   If-Match: "abc123"

   [
     { "op": "test", "path": "/a/b/c", "value": "foo" },
     { "op": "remove", "path": "/a/b/c" },
     { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
     { "op": "replace", "path": "/a/b/c", "value": 42 },
     { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
     { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
   ]

然而，JSON 合并补丁的工作方式不同。它定义了一些默认规则，指示服务器如何将更改应用于目标文档。像下面这样的文档，即在 c的属性 f 之后添加或更新字段 a 以使其具有值 z > 的对象必须被删除。该资源的所有其他剩余属性保持不变。

   PATCH /target HTTP/1.1
   Host: example.org
   Content-Type: application/merge-patch+json

   {
     "a":"z",
     "c": {
       "f": null
     }
   }

这两种媒体类型都可以用于直接向“集合”资源发送请求，因为它们都可以根据定义定位子元素。但是，在缓存方面，我会尽量避免。

HTTP 中的缓存实际上作用于资源的 URI。对该 URI 执行的任何不安全操作都会导致缓存使该目标的存储表示无效。 IE。如果您之前调用了GET /person/1，现在执行PUT 或PATCH，这两者都是不安全的操作，则在/person 上，数据可能会更新，尽管之后请求GET /person/1 的客户端仍可以通过以下方式检索缓存的响应缓存，因为它不知道对该资源所做的任何更改。

【讨论】：