使用contentType application/json而不是application/jsonpatch+json的java修补程序

Question

我有一个关于补丁内容类型的问题。我的应用程序是运行在公共云上的spring boot应用程序。 我担心的是Patch verb的contentType是否可以是application/json，而不是application/json Patch+json

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

Answer 1

any drawbacks if using plain-old json?

对

Patch verb could has the contentType to be application/json instead of application/json-patch+json?

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

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

a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.

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

Replace "ghoti" with "fish"

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

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

休息点的一部分是，这些协议应该有readily standardizable forms

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

此外，如果广告媒体类型是我已经知道的类型，我可以重复使用我以前的解决方案。拥有application/json补丁+json标准或application/merge补丁+json标准的一部分原因是，我们都以同样的方式理解这些文档。因此我们实现了互操作——任何应用程序/json补丁+json功能的客户端都可以成功地与任何应用程序/json补丁+json功能的服务器通信

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

例如，如果互操作在您的上下文中不重要，如果您同时控制服务器和客户机实现，那么按照某种通用标准进行调整也不那么重要。您的web页面承载与后端通信的java脚本，只要在这里很容易协调更改，这里使用的消息模式与其他地方使用的消息模式匹配就不是特别重要

<>但是如果你是在为“Web规模”的采用而努力，那么你需要在你的设计中考虑如何利用已经发布的通用工作。p>