在过去几年中，每当有人想要开始构建HTTP API时，他们几乎都将REST作为首选架构风格，而不是XML-RPC，SOAP和JSON-RPC等替代方法。REST被许多人制作成最终优于其他“基于RPC”的方法，这有点误导，RPC 与REST或其他风格都是各有千秋。
在REST变得流行之前（在Twitter和Facebook等公司将其API标记为REST之后），大多数API都是使用XML-RPC或SOAP构建的。XML-RPC存在问题，因为确保XML有效负载的数据类型很难。在XML中，很多东西都只是字符串，因此需要在上面对元数据进行分层，以便描述诸如哪些字段对应于哪些数据类型之类的内容，这成为SOAP（简单对象访问协议）基础的一部分。XML-RPC和SOAP以及自定义的本地解决方案长期以来一直主导着API领域，并且都是基于RPC的HTTP API。
“RPC”也称“远程过程调用”，它基本上与在JavaScript，PHP，Python等中调用函数，获取方法名称和参数相同。RPC API可以使用JSON-RPC协议，或者可以像Slack使用其Web API一样滚动自定义的基于JSON的API。
RPC Vs REST 存在很大的概念差异，即使它们看起来很相似：
- RPC。我们正在发送一条消息，这可能最终会在数据库中存储一些内容来保存历史记录，这可能是另一个可能具有相同字段名称的RPC调用 ，所以比较难判断。
- REST。我们正在用户的消息集合中创建消息资源。我们可以通过GET，在同一个URL上轻松查看这些历史记录，并在后台发送消息。
在规划新API时，了解REST和RPC之间的差异非常有用，或许使用两者并拥有两全其美！
分享到:
閱讀更多 常青春科技 的文章
關鍵字: 各有千秋 JSON JavaScript
