4 种主流的 API 架构风格对比

• 1. RPC：调用另一个系统的函数

  • RPC 的工作机制

  • RPC 的优势

  • RPC 的不足

  • RPC 的用例

• 2. SOAP：使数据作为服务可用

  • SOAP 的工作机制

  • SOAP 的优势

  • SOAP 的不足

  • SOAP 的用例

• 3. REST：使数据作为资源可用

  • REST 的工作机制

  • REST 的优势

  • REST 的不足

  • REST 的用例

• 4. GraphQL：仅请求所需要的数据

  • GraphQL 的工作机制

  • GraphQL 的优势

  • GraphQL 的不足

  • GraphQL 的用例

• 5. 哪种 API 模式最适用你的用例？

---

本文讨论了四种主要的 API 架构风格，比较它们的优缺点，并重点介绍每种情况下最适合的 API 架构风格。

两个单独的应用程序需要中介程序才能相互通信。因此，开发人员经常需要搭建桥梁——也就是应用程序编程接口（API），来允许一个系统访问另一个系统的信息或功能。

为了快速、大规模地集成不同的应用程序，API 使用协议或规范来定义那些通过网络传输的消息的语义和信息。这些规范构成了 API 的体系结构。

在过去，人们已经发布了多种不同的 API 架构风格。每个架构风格都有它独有的标准化数据交换的模式。这一系列的 API 架构风格的选项，引发了大量的关于哪种架构风格才是最好的争论。

今天，许多 API 的使用者将 REST 称作“消亡的 REST”（REST in peace），并且为 GraphQL 感到欢欣鼓舞。而十年前，又完全是另一幅光景：REST 是替代 SOAP 的赢家。这些观点的问题在于，它们的出发点只是为某种技术背书，而不是去考虑它实际的属性和特性如何与当前的需求相匹配。

1. RPC：调用另一个系统的函数

远程过程调用是一种允许在不同上下文中远程执行函数的规范。RPC 扩展了本地过程调用的概念，并将其放在 HTTP API 的上下文中。

最初的 XML-RPC 是存在问题的，因为很难确保 XML 有效负载的数据类型。因此，后来 RPC API 开始使用一个更具体的 JSON-RPC 规范，该规范被认为是 SOAP 的更简单的替代方案。gRPC 是 Google 在 2015 年开发的最新 RPC 版本。gRPC 可插拔支持负载均衡、追踪、运行状况检查和身份验证，它非常适合连接不同的微服务。

RPC 的工作机制

客户端调用一个远程的过程，将参数和附加信息序列化为消息，然后将消息发送到服务端。服务端在接受到消息后，将信息的内容反序列化，执行所请求的操作，然后将结果发送回客户端。客户端和服务端各自负责参数的序列化和反序列化。

RPC 的优势

简单直接的交互。 RPC 使用 GET 来获取信息，使用 POST 来处理其他所有操作。服务端和客户端之间交互的机制归结为调用端点并获得响应。

易于添加新函数。 如果 API 有了新的需求，我们可以轻松地添加另一个执行这个需求