以下是RFC 5789所说的：
PATCH方法请求将请求实体中描述的一组更改应用于由请求URI标识的资源。该组变化以称为"变化"的格式表示；补丁文档"；由媒体类型标识。如果请求URI没有指向现有资源，服务器可以根据补丁文档类型（是否可以逻辑修改空资源）和权限等创建新资源。
PUT和PATCH请求之间的差异反映在服务器处理封闭实体以修改由请求URI标识的资源的方式上。在PUT请求中，所包含的实体被认为是存储在源服务器上的资源的修改版本，并且客户端请求替换存储的版本。但是，对于PATCH，所附的实体包含一组指令，描述如何修改当前驻留在源服务器上的资源以生成新版本。
假设我有{ "login": "x", "enabled": true }，我想禁用它
根据帖子"；请不要像个白痴一样打补丁&"；，正确的PATCH请求是
[{ "op": "replace", "path": "/enabled", "value": false }]
然而，让我们接受这个请求：
{ "enabled": false }
它还"包含一组描述如何修改当前驻留在源服务器上的资源的指令"，唯一的区别是使用了JSON属性而不是JSON对象。
它似乎没有那么强大，但如果需要，数组更改可以有一些其他特殊的语法（例如{"a":{"add":[], "remove":[]}}），而且服务器逻辑可能无论如何都无法处理任何更强大的语法。
根据RFC，这是一个不正确的PATCH请求吗？如果是，为什么
另一方面，{ "op": "disable" }是否是正确的PATCH请求？
唯一的区别是使用了JSON属性而不是JSON对象。
事实上比这更深一点。参考RFC 6902是很重要的。第一个请求的Content-Type为application/json-patch+json，但第二个请求为application/json
重要的是，你要使用一个"diff-media类型"，这个类型对这个目的很有用。你不必使用JSON-PATCH（我是JSON合并补丁的忠实粉丝），但你不能只使用任何你想要的东西。你在第二部分中问的基本上是"我能制作自己的媒体类型吗"，答案是"可以"，只是请记录下来并在IANA注册。