有很多比较像“REST vs smth”（例如vs Kafka、vs JSON-RPC），但我也看到JSON-RPC和JSON Patch之间有很多相似之处——它们都指定了操作/方法、值/parameters，并允许执行批处理请求。我看到的唯一区别是 JSON-RPC 还描述了带有 ID 和错误的响应格式，因此看起来更成熟。但也许他们只是有不同的优缺点，不同的合适用例？
【问题讨论】：
标签： json json-rpc json-patch
JSON-RPC (2.0) 确实大部分被提及为 REST 替代方案。 （看看更一般的讨论，REST vs SOAP vs RPC 可能会到期，但这是一个严重的问题。部分问题是，人们谈论不同的 REST 和 RPC 以及 confuse them。 ) 从历史上看，RPC systems 经常遭受与模式要求、自定义序列化、协议限制和复杂 RPC/函数映射相关的混淆依赖。 JSON-RPC 试图纠缠依赖关系，它不想成为所有人的一切 RPC，而是保持相对狭窄的范围。它支持少量（更）命令集，并且对如何实现它更加固执己见。尽管如此，它是一个完整的包，高度灵活，用于struggle to map all operations to HTTP verbs 的复杂 API。事件、通知和批处理操作等较新的功能使 JSON-RPC 非常通用，是各种项目的不错选择；这些新增功能对于基于操作的微服务特别有用。
JSON-Patch (RFC6902) 可以说是试图解决 API 的一个常见问题，即部分更新。 JSON Patch 提供了一个原子更新请求来修补您的 JSON一系列“添加”、“删除”、“替换”、“移动”和“复制”操作。 To quote JSON Patch RFC 的作者之一，Mark Nottingham (IETF)：
这有很多优点。由于它是通用格式，因此您可以 一次编写服务器端和客户端代码，并在多个数字之间共享 的应用程序。您可以进行一次 QA，并确保您做对了。 此外，您的 API 将变得不那么复杂，因为它的 URI 约定，带来更大的灵活性并使其更容易 新开发人员的方法。使用这种方法也会使缓存 操作更正确；因为对资源的修改会 “旅行”通过其 URL，而不是其他某个 URL，存储的权利 响应将失效。
关于JSON Merge Patch (RFC7396 可以说类似的事情，它可以用于相同的目的，但更像是一个简单地包含更改而不是使用变异操作的差异/补丁。在这方面，JSON Merge Patch 比 JSON Patch 更简单但更受限制，例如您不能将键设置为 null（因为 null 表示删除），合并仅适用于对象 {..}，数组 [..] 只能作为一个整体替换，并且合并永远不会失败，可能会导致副作用，因此不是事务性的。这使得 Merge Patch（过度）简单化并且对于某些实际应用程序不切实际。还有更多相关的项目，如 JSON-Diffpatch 等，采用类似的方法。
一般来说，它们都有优点和缺点，而且没有一个适合每个人的用例。这真的取决于what problems you want to solve with your APIs。 JSON-RPC 可以说是更加通用和成熟，但是，JSON-Patch 也是一个不错的选择，特别是如果您控制通信的双方。
【讨论】：