根据HTTP PATCH RFC,文档的部分表示是有效的“更改集”吗?

时间:2014-09-03 02:18:01

标签: http-patch

以下是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请求?

1 个答案:

答案 0 :(得分:2)

  

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

它实际上比那更深一些。 RFC 6902的引用很重要。第一个请求的Content-Typeapplication/json-patch+json,但第二个请求为application/json

重要的是你使用的是差异媒体类型,'一个对此目的有用的。你不必使用JSON-PATCH,(我是json-merge-patch的忠实粉丝),但你不能只使用你想要的任何东西。您在第二部分中提出的问题基本上是“我可以制作自己的媒体类型”。答案是'是的,'请将其记录下来并在IANA注册。