有没有人可以解释在json-api上使用json-rpc的优势，反之亦然？第一种和第二种格式是基于JSON的，但在哪里我应该使用一种，哪一种是另一种？
答案 0 :(得分：8)
注意：我可能会遇到一些偏见。我是Json-RPC.ne服务器库的作者。
Json-RPC 是远程过程调用规范。您可以使用多个库来使用该协议进行通信。它不是基于REST的，并且与传输无关。您可以通过HTTP运行它，这是非常常见的，您也可以通过套接字或您认为合适的任何其他传输方式使用它。所以在这方面非常灵活。您还可以通过在客户端或服务器上托管RPC服务器，将服务器与客户端连接到服务器请求。
Json-API 是用于构建REST API的规范。您可以使用多个库来开始使用它。与Json-Rpc相比，它要求您在HTTP服务器上托管它。您无法使用它在客户端上调用函数。您无法通过非http传输协议运行它。基于REST，它擅长提供有关资源的信息。如果您想要一个基于创建，读取，更新，删除某些资源集合的API的API，那么这可能是一个不错的选择。
如果您的API是基于资源的，那么Json-API会更好，并且您希望您的API可以被人类浏览，而无需为其设置文档。虽然人类可能需要进入软件工程领域才能理解它。 如果你的API是基于功能的，或者你想要它提供的灵活性，那么Json-RPC会更好。 Json-RPC仍然可以通过为您的资源创建创建，读取，更新和删除功能来操作资源，但是您不能通过它而不是基于REST的可浏览性。通过基于您公开的函数生成文档，人类仍然可以探索（而不是浏览）。使用Json-Rpc的一个流行的例子是BitCoin。
有许多流行的基于REST的API，而Json-API是一个带有大量工具的规范，可以帮助您正确地进行REST。
-
注意：当您考虑开发人员的时间，性能或有效使用网络资源时，这两者（Json-RPC或Json-API）都不是很好。
如果您关心性能，效率或开发人员时间，那么请查看Google gRPC，这对于这些问题非常棒，并且与使用REST API相比，仍然可以减少开发人员的时间，因为客户端和服务器代码可以从协议定义文件生成。