以下是RFC 5789所说的内容：
PATCH方法请求将请求实体中描述的一组更改应用于Request-URI标识的资源。该组更改以称为“补丁文档”的格式表示，该格式由媒体类型标识。如果Request-URI未指向现有资源，则服务器可以创建新资源，具体取决于补丁文档类型（是否可以逻辑修改空资源）和权限等。
PUT和PATCH请求之间的差异反映在服务器处理随附实体以修改Request-URI标识的资源的方式中。在PUT请求中，封闭的实体被认为是存储在源服务器上的资源的修改版本，并且客户端正在请求替换所存储的版本。但是，使用PATCH时，附带的实体包含一组指令，描述如何修改当前驻留在源服务器上的资源以生成新版本。
假设我有{ "login": "x", "enabled": true }，我想禁用它。
根据帖子"Please. Don't Patch Like An Idiot."，正确的PATCH请求将是
[{ "op": "replace", "path": "/enabled", "value": false }]
但是，我们接受这个请求：
{ "enabled": false }
它还包含一组描述如何修改当前驻留在源服务器上的资源的指令，唯一的区别是使用了JSON属性而不是JSON对象。
它似乎不那么强大，但是如果需要，数组更改可以有一些其他特殊语法（例如{"a":{"add":[], "remove":[]}}），并且服务器逻辑可能无法处理任何更强大的任何东西。
根据RFC，它是不正确的PATCH请求吗？如果是这样，为什么？
而另一方面，{ "op": "disable" }是否是正确的PATCH请求？
答案 0 :(得分：2)
唯一的区别是使用了JSON属性而不是JSON对象。
它实际上比那更深一些。 RFC 6902的引用很重要。第一个请求的Content-Type为application/json-patch+json，但第二个请求为application/json
重要的是你使用的是差异媒体类型，＆＃39;一个对此目的有用的。你不必使用JSON-PATCH，（我是json-merge-patch的忠实粉丝），但你不能只使用你想要的任何东西。您在第二部分中提出的问题基本上是“我可以制作自己的媒体类型”。答案是'是的，＆＃39;请将其记录下来并在IANA注册。