1RPC：调用另一个系统的函数
RPC 的工作机制
客户端调用一个远程的过程，将参数和附加信息序列化为消息，然后将消息发送到服务端。服务端在接受到消息后，将信息的内容反序列化，执行所请求的操作，然后将结果发送回客户端。客户端和服务端各自负责参数的序列化和反序列化。
RPC 的优势
简单直接的交互。 RPC 使用 GET 来获取信息，使用 POST 来处理其他所有操作。服务端和客户端之间交互的机制归结为调用端点并获得响应。
易于添加新函数。 如果 API 有了新的需求，我们可以轻松地添加另一个执行这个需求的端点：1）编写一个新函数，并将其放在一个新端点之后；2）现在，客户可以访问这个端点，并获取符合其需求的信息。
高性能。轻量级的有效负载不会对网络产生压力，以此提供高性能，这对于共享服务器和在工作站网络上执行并行计算非常重要。RPC 还能够优化网络层，使得不同服务之间每天发送海量消息变得非常高效。
RPC 的不足
RPC 的紧密耦合使得可伸缩性要求和松散耦合的团队难以实现。因此，客户端要么会担心调用特定端点的带来的任何可能的副作用，要么需要尝试弄清楚要调用的端点，因为客户端不了解服务器如何命名其函数。
可发现性低。 在 RPC 中，无法对 API 进行检验总结，或者发送请求来开始理解根据需求应该调用哪个函数。
函数爆炸性增长。创建新函数非常容易。因此，相较于重新编辑现有的函数，我们会倾向于创建新的功能，最终产生大量难以理解的、功能重叠的函数。
2SOAP：使数据作为服务可用
SOAP 的优势
独立于语言和平台。内置创建 Web 服务的功能使得 SOAP 能够处理消息通信的同时发送独立于语言和平台响应。
绑定到各种协议。SOAP 在适用于多种场景的传输协议方面是十分灵活的。
内置错误处理。SOAP API 规范允许返回带有错误码及其说明的的 XML 重试消息。
一系列的安全拓展。SOAP 与 ES-Security 集成，因此 SOAP 可满足企业级事务要求。它在事务内部提供了隐私和完整性，同时允许在消息级别进行加密。
3REST：使数据作为资源可用
REST 的工作机制
REST 的定义并不像 SOAP 那样严格。RESTful 体系结构应该遵守如下六个体系结构约束：
- 统一接口：无论设备或应用程序类型如何，都可以采用统一的方式与给定的服务端进行交互。
- 无状态：请求本身包含处理该请求所需要的状态，并且服务端不存储与会话相关的任何内容。
- 缓存
- 客户端 - 服务器体系结构：允许双方独立发展
- 应用程序的层级系统
- 服务端向客户端提供可执行代码的能力
实际上，某些服务仅在某种程度上是 RESTful 的。而它们的内核采用了 RPC 样式，将较大的服务分解为资源，并有效地使用 HTTP 基础结构。但 REST 的关键部分是超媒体（又称 HATEOAS），是超文本作为应用程序状态引擎（Hypertext As The Enginer Of Application State）的缩写。
REST 的优势
客户端和服务端的解耦：由于 REST 尽可能地解耦了客户端和服务端，REST 相较于 RPC 可以提供更好的抽象性。具有抽象级别的系统能够封装其实现细节，以更好的标示和维持它的属性。这使得 REST API 足够灵活，可以随着时间的推移而发展，同时保持稳定的系统。
可发现性：客户端和服务端之间的通信描述了所有内容，因此不需要外部文档即可了解如何与 REST API 进行交互。
缓存友好：REST 重用了许多 HTTP 工具，也是唯一一种可以在 HTTP 层面上缓存数据的 API 架构风格。与其相对的是，在任何其他 API 上实现缓存都需要配置其他缓存模块。
多种格式支持：REST 拥有支持多种格式用于存储和交换数据的能力，这是它如今成为搭建公共 API 的主要选择的原因之一。
REST 的不足
没有标准的 REST 结构：在构建 REST API 方面，没有具体的正确方法。如何对资源进行建模以及哪些资源需要建模取决于不同的情况。这使得 REST 在理论上很简单，但在实践中却很困难。
庞大的负载： REST 会返回大量丰富的元数据，以便客户端可以仅从响应中了解有关应用程序状态的所有必要信息。对于具有大量带宽容量的大型网络系统来说，这种“啰嗦”的通信并不算很大的负载。但带宽容量并非总是足够的。这也是 Facebook 在 2012 年提出 GraphQL 架构风格的关键驱动因素。
响应过度和响应不足问题。REST 的响应包含的数据会过多或不足，通常会导致客户端需要发送另一个请求。
4GraphQL：仅请求所需要的数据
GraphQL 的工作机制
GraphQL 从构建模式（Schema）开始。模式是对于用户可以在 GraphQL API 中进行的所有查询及其返回的所有类型的描述。模式构建非常困难，因为它需要使用模式定义语言（SDL）进行强类型化。
因为在客户端进行查询之前已经定义好了模式，所以客户端可以验证其查询语句，以确保服务端能够对查询语句进行响应。在查询语句到达后端应用程序时，GraphQL 操作将根据整个模式进行解释，并向前端应用程序返回解析到的数据。API 向服务端发送一个庞大的查询，该 API 返回一个仅包含我们所需数据的 JSON 响应。
GraphQL 的优势
具有类型的模式：GraphQL 提前公开了它能做什么，从而提高了其可发现性。通过将客户端指向 GraphQL API，我们可以发现什么查询语句是可用的。
没有版本控制：版本控制的最佳实践是不要对 API 进行版本控制。
尽管 REST 提供了不同的 API 版本，GraphQL 使用的是不断更新的单一版本，这使用户可以持续访问新功能，并有助于提供更整洁、更可维护的服务器代码。
详细的错误消息：GraphQL 以类似于 SOAP 的方式提供所发生错误的详细信息。它的错误消息包括所有解析器，并指向确切的发生故障时的查询部分。
灵活的权限：GraphQL 允许选择性地公开某些功能，同时保留私人信息。而相对应的是，REST 体系架构不能仅显示部分数据，要么是全部数据，要么是没有数据。
GraphQL 的不足
性能问题。GraphQL 权衡了复杂性，来实现其强大功能。一个请求中的嵌套字段太多会导致系统过载。因此，对于复杂的查询，REST 仍然是更好的选择。
缓存复杂度。由于 GraphQL 不再使用 HTTP 缓存语义，因此使用者需要额外自定义缓存。
大量的预开发教育。由于没有足够的时间来了解 GraphQL 的某个操作和 SDL，因此许多项目决定采用众所周知的 REST 方法。