API架构风格

1. RPC

调用另一个系统的函数，

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

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

RPC 的工作机制

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

RPC 的优势

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

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

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

RPC 的不足

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

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

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

函数爆炸性增长 。创建新函数非常容易。因此，相较于重新编辑现有的函数，我们会倾向于创建新的功能，最终产生大量难以理解的、功能重叠的函数。

RPC 的用例

RPC 模式在八十年代开始使用，但这并不意味着它已经过时了。诸如 Google、Facebook（Apache Thrift）和 Twitch（Twirp）这样的大公司如今正在内部使用高性能的 RPC 版本，来执行极高性能、低开销的消息传递。它们庞大的微服务系统要求内部通信在使用短消息的情况下也保持清晰。

命令 API 。RPC 是用于将命令发送到远程系统的正确选择。例如，Slack API 是非常以命令为中心的：加入频道、离开频道、发送消息。因此，Slack API 的设计者以类似于 RPC 的样式对其进行了建模，使其小巧、紧凑并且易于使用。

用于内部微服务的客户特定的 API 。由于是在单个提供者和单个使用者之间建立直接的集成，我们不想像 REST API 那样，花太多时间通过网络传输大量的元数据。凭借高消息速率和消息性能，gRPC 和 Twirp 成为了用于微服务的可靠用例。通过在底层使用 HTTP 2，gRPC 能优化网络层，使其非常高效地在不同服务之间每天传送大量信息。然而，如果你并不是要着眼于提高网络性能，而是要在发布高度独立的微服务团队之间建立一个稳定的 API 联系。REST 就能做到。

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

SOAP 是一个 XML 格式的、高度标准化的网络通讯协议。在 XML-RPC 发布的一年后，SOAP 由微软发布、并继承了许多 XML-RPC 的特性。在 REST 紧随其后发布，一开始它们是被同时使用，但很快 REST 赢得了这次比赛，成为了更流行的协议。

SOAP 的工作机制

XML 数据格式拖累了很多数据规范。伴随着大量的消息结构，XML 数据格式使得 SOAP 成为了最冗长的 API 架构风格。

SOAP 的消息由这些部件组成：

• 一个信封标签：用于开始和结束每条消息

• 包含请求或响应的正文

• 一个标头：用于表示消息是否由某些规范或额外要求的来确认

• 故障通知：包含了可能在请求处理过程只能够发生的任何错误

一个 SOAP 消息的例子，图源：IBM

SOAP API 的逻辑由 Web 服务描述语言（WSDL）编写。该 API 描述语言定义了端点并描述了可以执行的所有过程。这使得不同的编程语言和 IDE 能够快速建立通信。

SOAP 支持有状态和无状态消息传递。在有状态的情况下，服务器存储接收到的信息可能非常繁琐复杂。但这对于涉及多方和复杂交易的操作是合理的。

SOAP 的优势

独立于语言和平台 。内置创建 Web 服务的功能使得 SOAP 能够处理消息通信的同时发送独立于语言和平台响应。

绑定到各种协议 。SOAP 在适用于多种场景的传输协议方面是十分灵活的。

内置错误处理 。SOAP API 规范允许返回带有错误码及其说明的的 XML 重试消息。

一系列的安全拓展 。SOAP 与 ES-Security 集成，因此 SOAP 可满足企业级事务要求。它在事务内部提供了隐私和完整性，同时允许在消息级别进行加密。

SOAP 消息级别的安全性：在标头元素的认证数据以及加密的正文

SOAP 的不足

如今，由于如下几种原因，许多开发人员在听到必须集成 SOAP API 的想法后都会感到不安。

仅使用 XML 。SOAP 消息包含大量的元数据，并且在请求和响应时仅支持繁冗的 XML 格式。

重量级 。由于 XML 文件的大小，SOAP 服务需要很大的带宽。

非常专业化的知识 。构建 SOAP API 服务器需要对所有涉及到的协议以及它们及其严格的限制都有很深的了解。

乏味的消息更新 。由于需要额外的工作来添加或者删除某个消息属性，这种死板的 SOAP 模式减慢了其被采用的速度。

SOAP 的用例

目前，SOAP 体系结构最常用于企业内部或与其信任的合作伙伴的内部集成。

高度安全的数据传输 。SOAP 严格的消息结构，安全性和授权功能使其成为在 API 和客户端之间执行正式软件协议的最合适的选择，同时又符合 API 提供者与 API 使用者之间的法律合同。这就是为什么金融组织和其他企业用户选择适用 SOAP 的原因。