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

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

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

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

不同时间的 API 架构风格，图源：Rob Crowley

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

四种 API 架构风格

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

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

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

RPC 的工作机制

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

远程过程调用的机制，图源：Guru99

RPC 的优势

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

易于添加新函数。 如果 API 有了新的需求，我们可以轻松地添加另一个执行这个需求的端点：1）编写一个新函数，并将其放在一个新端点之后；2）现在，客户可以访问这个端点，并获取符合其需求的信息。

高性能。 轻量级的有效负载不会对网络产生压力，以此提供高性能，这对于共享服务器和在工作站网络上执行并行计算非常重要。RPC 还能够优化网络层，使得不同服务之间每天发送海量消息变得非常高效。

RPC 的不足

和底层系统紧密耦合。 API 的抽象级别有助于其可重用性。API 与基础系统的耦合越紧密，对其他系统的可重用性就越差。 RPC 与基础系统的紧密耦合不允许其在系统函数和外部 API 之间建立抽象层。这很容易引起安全问题，因为关于基础系统的细节实现很容易会泄漏到 API 中。

RPC 的紧密耦合使得可伸缩性要求和松散耦合的团队难以实现。因此，客户端要么会担心调用特定端点的带来的任何可能的副作用，要么需要尝试弄清楚要调用的端点，因为客户端不了解服务器如何命名其函数。

可发现性低。 在 RPC 中，无法对 API 进行检验总结，或者发送请求来开始理解根据需求应该调用哪个函数。

函数爆炸性增长。 创建新函数非常容易。因此，相较于重新编辑现有的函数，我们会倾向于创