4

这是RFC 5789所说的：

PATCH 方法请求将请求实体中描述的一组更改应用于由 Request-URI 标识的资源。这组更改以一种称为“补丁文档”的格式表示，该格式由媒体类型标识。如果 Request-URI 不指向现有资源，则服务器可以创建新资源，具体取决于补丁文档类型（是否可以在逻辑上修改空资源）和权限等。

PUT 和 PATCH 请求之间的区别体现在服务器处理封闭实体以修改由 Request-URI 标识的资源的方式上。在 PUT 请求中，包含的实体被认为是存储在源服务器上的资源的修改版本，并且客户端请求替换存储的版本。然而，对于 PATCH，封闭的实体包含一组指令，描述如何修改当前驻留在源服务器上的资源以生成新版本。

假设我有{ "login": "x", "enabled": true }，我想禁用它。

根据帖子“请。不要像白痴一样修补。” ，正确的 PATCH 请求将是

[{ "op": "replace", "path": "/enabled", "value": false }]

但是，让我们接受这个请求：

{ "enabled": false }

它还“包含一组说明如何修改当前驻留在源服务器上的资源”，唯一的区别是使用 JSON 属性而不是 JSON 对象。

它似乎不太强大，但如果需要，数组更改可以有一些其他特殊语法（例如{"a":{"add":[], "remove":[]}}），并且服务器逻辑可能无法处理任何更强大的东西。

根据 RFC，这是不正确的 PATCH 请求吗？如果是这样，为什么？
另一方面，一个正确的 PATCH 请求会{ "op": "disable" }是一个正确的 PATCH 请求吗？

4

1 回答 1

2

唯一的区别是使用 JSON 属性而不是 JSON 对象。

它实际上比这更深一些。对RFC 6902的引用很重要。第一个请求具有Content-Typeof application/json-patch+json，但第二个请求是application/json

重要的是您使用“差异媒体类型”，这对于此目的很有用。你不必使用 JSON-PATCH，（我是json-merge-patch的忠实粉丝），但你不能只使用你想要的任何东西。您在第二部分中询问的内容基本上是“我可以制作自己的媒体类型吗”，答案是“可以”，只需将其记录在案并在 IANA 注册即可。

于 2014-09-09T23:41:17.713 回答