JSON-RPC vs JSON修补程序

Question

有很多类似“REST vs SMTH”的比较（例如vs Kafka,vs JSON-RPC)，但我也看到了JSON-RPC和JSON补丁之间的许多相似之处--它们都指定了操作/方法、值/参数，并允许执行批处理请求。我看到的唯一区别是，JSON-RPC还用ID和错误描述响应格式，因此看起来更加成熟。但也许它们只是有不同的优点和缺点，不同的合适用例？

Answer 1

JSON-RPC(2.0)确实是作为REST的替代方案而被提到的。（看看更一般的讨论，REST vs SOAP vs RPC可能是应该的，但这是一个兔子洞，严重的。部分问题是，人们谈论不同的REST和RPC并混淆了它们。）在历史上，RPC系统经常受到与模式需求、自定义序列化、协议限制和复杂的RPC/函数映射相关的混乱依赖关系的困扰。JSON-RPC试图纠缠依赖关系，它不想成为每个人的所有RPC，而是保持相对狭窄的范围。它支持一个很小的(er)命令集，并且对于如何实现它更加固执己见。尽管如此，它是一个完整的包，高度灵活，并用于那些难以将所有操作映射到HTTP谓词的复杂API。更新的功能,如事件、通知和批处理操作,使JSON-RPC具有很强的通用性,是各种项目的良好选择；这些添加对于基于操作的微服务特别有用。

可以说，JSON-Patch(RFC6902)试图解决API的一个常见问题，即部分更新。与putting或posting（可能是重量级的）更改到（历史上）增长的URL空间、使用查询参数携带语义或引入其他复杂性不同，JSON修补程序提供了原子更新请求，它使用一系列“添加”、“删除”、“替换”、“移动”和“复制”操作对JSON进行修补。引用JSON补丁RFC的作者之一Mark Nottingham(IETF)的话：

这有很多好处。由于它是一种通用格式，您可以一次性编写服务器端和客户端代码，并在多个应用程序之间共享。你可以做一次QA，并确保你做对了。此外，您的API将变得不那么复杂，因为它有更少的URI约定，从而带来更多的灵活性，使新开发人员更容易接近。使用这种方法还会使缓存更正确地运行；由于对资源的修改将通过其URL而不是其他URL进行“传递”，因此正确存储的响应将会失效。

对于JSON合并补丁(RFC7396)也可以说类似的事情，它可以用于相同的目的，但更像是一个diff/补丁，它只是包含更改，而不是使用变异操作。在这方面，JSON合并修补程序比JSON修补程序更简单，但更有限，例如，您不能将键设置为null（因为null意味着删除），合并仅适用于对象{..}，数组[..]只能作为一个整体替换，并且合并从不失败，可能导致副作用，因此不是事务性的。这使得合并补丁（过于）简单化，对于某些现实世界的应用程序来说是不切实际的。还有更多的相关项目，如JSON-Diffpatch等，采用了类似的方法。

总的来说，它们都有优点和缺点，但没有一个适合每个人的用例。这实际上取决于您想用API解决什么问题。JSON-RPC可以说是更加通用和成熟的，但是，JSON-Patch也是一个很好的选择，特别是如果您控制html" target="_blank">通信的双方。