使用 contentType application/json 而不是 application/json-patch+json 的 PATCH

Question

我对 PATCH 内容类型有疑问。我的应用程序是在公共云上运行的 Spring Boot 应用程序。 我担心的是，如果 Patch 动词的 contentType 可以是 application/json 而不是 application/json-patch+json？

如果使用普通的 json 有什么缺点吗？

Answer 1

如果使用普通的 json 有什么缺点吗？

是的

补丁动词的 contentType 可以是 application/json 而不是 application/json-patch+json？

• 可以
• 这不是特别有用
• 你可能不在乎它不是特别有用

HTTP Patch 说我们应该在请求中包含一个补丁文档，其中包含

一组说明如何修改当前驻留在源服务器上的资源以生成新版本。

PATCH /foo HTTP/1.1
Content-Type: text/plain

Replace "ghoti" with "fish"

这是一个格式完美的补丁请求，建议对 /foo 资源进行编辑

但是：请注意，此示例中存在一些歧义——此补丁是否说要替换一个 ghoti 实例？还是每个 ghoti 实例？如果我们想确保客户端和服务器以相同的方式理解此消息，那么他们需要在这一点上达成某种协议。

REST 的部分要点是这些协议应该有readily standardizable forms。

关于服务器支持的补丁文档的协议本身由 Accept-Patch 标头（在 HTTP Patch 规范中定义）描述；标头值是媒体类型；然后我可以找到该媒体类型的定义来弄清楚如何描述我的更改。

此外，如果宣传的媒体类型是我已经知道的，我可以重新使用我以前的解决方案。拥有 application/json-patch+json 标准或 application/merge-patch+json 标准的部分意义在于我们都以相同的方式理解这些文档。所以我们得到了互操作——任何支持 application/json-patch+json 的客户端都可以成功地与任何支持 application/json-patch+json 的服务器通信。

application/json 不能以这种方式工作，因为 JSON 规范中没有任何内容可以创建对如何在 PATCH 上下文中解释 JSON 文档的共同理解。相反，您需要一些其他“带外”信息来做正确的事情。

如果互操作在您的上下文中并不重要（例如，如果您同时控制服务器和客户端的实现），那么与某个通用标准保持一致也不是那么重要。您的网页托管与您的后端通信的 java 脚本，只要在这里可以轻松协调更改，此处使用的消息模式与其他地方使用的相匹配并不是特别重要。

但是，如果您正在努力实现“网络规模”采用，那么您需要在设计中考虑如何利用已发布的通用工作。