这是什么RFC 5789 https://www.rfc-editor.org/rfc/rfc5789 says:
PATCH 方法请求将请求实体中描述的一组更改应用于由 Request-URI 标识的资源。这组更改以称为“补丁文档”的格式表示，该格式由媒体类型标识。如果Request-URI没有指向现有资源，服务器可以创建一个新资源，具体取决于补丁文档类型（是否可以逻辑上修改空资源）和权限等。
PUT 和 PATCH 请求之间的差异反映在服务器处理所附实体以修改 Request-URI 标识的资源的方式上。在 PUT 请求中，所包含的实体被认为是存储在源服务器上的资源的修改版本，并且客户端请求替换存储的版本。然而，对于 PATCH，所附实体包含一组指令，描述应如何修改当前驻留在源服务器上的资源以生成新版本。
假设我有{ "login": "x", "enabled": true }，我想禁用它。
根据帖子“拜托。别像白痴一样打补丁。” http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/，正确的 PATCH 请求是
[{ "op": "replace", "path": "/enabled", "value": false }]
但是，让我们接受这个请求：
{ "enabled": false }
它还“包含一组说明如何修改当前驻留在源服务器上的资源”，唯一的区别是使用 JSON 属性而不是 JSON 对象。
它看起来不太强大，但如果需要的话，数组更改可以有一些其他特殊语法（例如{"a":{"add":[], "remove":[]}}），并且服务器逻辑可能无法处理任何更强大的东西。
根据 RFC，这是否是不正确的 PATCH 请求？如果是这样，为什么？
并且，另一方面，{ "op": "disable" }是一个正确的 PATCH 请求吗？
唯一的区别是使用 JSON 属性而不是 JSON 对象。
实际上比这更深一点。参考RFC 6902 https://www.rfc-editor.org/rfc/rfc6902很重要。第一个请求有一个Content-Type of application/json-patch+json，但第二个是application/json
重要的是您使用一种对此目的有用的“不同媒体类型”。你不必使用 JSON-PATCH，（我是json 合并补丁 https://datatracker.ietf.org/doc/html/draft-ietf-appsawg-json-merge-patch-07），但你不能只使用你想要的任何东西。您在第二部分中询问的基本上是“我可以制作自己的媒体类型吗”，答案是“可以”，只需将其记录下来并向 IANA 注册即可。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
