了解 API 协议：SOAP、REST、JSON-RPC、gRPC、GraphQL、Thrift

超、凢脫俗 2023-10-01 17:36 90阅读 0赞

[Know your API protocols: SOAP vs. REST vs. JSON-RPC vs. gRPC vs. GraphQL vs. Thrift][Know your API protocols_ SOAP vs. REST vs. JSON-RPC vs. gRPC vs. GraphQL vs. Thrift]

曾几何时——特别是在 2000 年代初期——只有两个真正的 API 协议是大多数开发人员必须知道的：SOAP 和 REST。然而，近年来，新类型的 API 协议激增，例如 RPC 和 GraphQL。

这意味着，如果您开发一个应用程序（尤其是如果您开发一个将托管在云中或将以某种方式与云服务连接的应用程序），您必须考虑当前可用的不同 API 协议。  
  
为此，这里有一个关于当今排名前六位的 API 协议的入门指南。  
  
***TL;DR**：这是一个协议比较概述*

![format_png][]

### 肥皂 ###

我们将从 SOAP 开始，它是仍然广泛使用的最古老的以 Web 为中心的 API 协议。SOAP 于 1990 年代后期推出，是最早设计用于允许不同应用程序或服务使用网络连接以系统方式共享资源的协议之一。  
  
（我应该注意到，从技术上讲，SOAP 是远程过程调用或 RPC 的一个示例。RPC 是允许不同计算机相互通信的一大类方法。它自 1970 年代就已经存在，并且远远超出Web 应用程序。这就是为什么我没有将 RPC 作为一个单独的项目包含在这个“现代”API 协议列表中。但是要知道，如果你想深入了解 SOAP 的历史以及使之成为可能的概念，你必须从 RPC 开始。）  
  
SOAP 代表简单对象访问协议。一些开发人员可能会质疑 SOAP 是“简单”的概念，因为使用 SOAP 协议需要大量的工作。您必须创建 XML 文档才能进行调用，而 SOAP 所需的 XML 格式并不完全直观。这不仅使调用实现变得困难，而且使问题难以调试，因为调试需要解析长字符串的复杂数据。  
  
另一方面，SOAP 依赖于标准协议，尤其是 HTTP 和 SMTP。这意味着您可以在几乎所有类型的环境中使用 SOAP，因为这些协议在所有操作系统上都可用。

### 休息 ###

REST 是 Representational State Transfer 的缩写，是一种 API 协议，由 Roy Fielding 在 2000 年的一篇论文中引入，其目标是解决 SOAP 的一些缺点。  
  
与 SOAP 一样，REST 依赖于标准传输协议 HTTP，在不同的应用程序或服务之间交换信息。但是，REST 更灵活，因为它支持多种数据格式，而不需要 XML。JSON 可以说比 XML 更容易读写，是许多开发人员用于 REST API 的格式。REST API 还可以提供比 SOAP 更好的性能，因为它们可以缓存信息。  
  
根据 Cloud Elements 2017 年的一份报告，REST API 占当年所有 API 类型的 83%（尽管该报告并未研究所有 API 协议）。

### JSON-RPC ###

虽然 REST 支持 RPC 数据结构，但它并不是该类别中唯一的 API 协议。如果您喜欢 JSON，您可能更喜欢使用 JSON-RPC，这是 2000 年代中期引入的协议。  
  
与 REST 和 SOAP 相比，JSON-RPC 的范围相对狭窄。它支持一小组命令，并且在具体实现方式方面没有提供像 REST 这样的协议那样的灵活性。但是，如果您喜欢简单性并且有一个属于 JSON-RPC 范围的简单用例，那么它可能是比 REST 更好的解决方案。

### gRPC ###

上面，我对 RPC 进行了附加讨论，RPC 是构成 SOAP 基础的远程调用体系结构的一个广泛类别。  
  
gRPC 是一个开源 API，也属于 RPC 的范畴。然而，与 SOAP 不同的是，gRPC 更新得多，已于 2015 年由 Google 公开发布。（也就是说，gRPC 的历史可以追溯到 Google 的一个名为 Protocol Buffers 的内部项目，该项目始于 2001 年。）  
  
与 REST 和 SOAP 一样，gRPC使用 HTTP 作为其传输层。然而，与这些其他 API 协议不同的是，gRPC 允许开发人员定义他们想要的任何类型的函数调用，而不必从预定义的选项中进行选择（例如 REST 中的 GET 和 PUT）。  
  
gRPC 的另一个重要优势（至少对于许多用例而言）是，当您使用 gRPC 调用远程系统时，该调用在发送方和接收方看来就像是本地调用，而不是远程调用通过网络执行。这种模拟避免了许多编码复杂性，否则您必须为应用程序处理远程调用而应对这些复杂性。  
  
gRPC 简化原本复杂的远程调用的能力使其在为微服务或基于 Docker 的应用程序构建 API 的环境中流行起来，这需要大量的远程调用。

### GraphQL ###

在某种程度上，GraphQL 之于 Facebook 就像 gRPC 之于 Google：它是一种 API 协议，由 Facebook 于 2013 年内部开发，然后于 2015 年公开发布。因此，官方定义为查询语言的 GraphQL 也代表了一种努力克服 REST 的一些限制或低效率。  
  
REST 和 GraphQL 之间的主要区别之一是 GraphQL 允许客户端在向服务器发出调用时按照他们想要的方式构造数据。这种灵活性提高了效率，因为这意味着客户端可以优化他们请求的数据，而不必以服务器提供的任何预打包形式请求和接收数据（这可能需要接收比客户端实际需要的更多的数据，或者以难以使用的格式）。使用 GraphQL，客户可以准确地得到他们想要的东西，而不必担心在收到数据后在本地转换数据。

### 阿帕奇节俭 ###

与 GraphQL 一样，Apache Thrift 诞生于 Facebook（它现在是一个由 Apache 软件基金会托管的开源项目），本质上是一个 RPC 框架。然而，Thrift 的设计目标和目标用例与 GraphQL 有很大不同。  
  
Thrift 的主要卖点是一旦定义了服务，就可以轻松地修改服务使用的协议。结合 Thrift 还支持一系列不同的传输方法和几种不同的服务器进程实现的事实，这意味着 Thrift 非常适合您希望经常修改或更新您的 API 架构和实现的情况。您可能会说 Thrift 非常适合避免“API 架构锁定”，因为它确保您可以在需要时轻松更改 API 架构，而不是因为 API 不灵活而被迫保持相同的架构。  
  
另一方面，一些开发人员可能会争辩说，在实现 API 时 Thrift 为您提供的选择并不理想，因为与仅提供一种处理方式的其他 API 协议相比，它会导致一致性较差。如果您喜欢严格的一致性和可预测性，Thrift 可能不是您的最佳选择。

### 结论 ###

如果您今天是一名程序员，那么拥有如此多的 API 协议供您使用，您会觉得自己很幸运。虽然 20 年前 SOAP（以及稍后的 REST）是城里唯一的游戏，但现在您也可以从 gRPC、GraphQL、Thrift 和 JSON-RPC 中进行选择。这些协议中的每一个都有各种优点和缺点，因此很容易找到最适合您情况的协议。

[Know your API protocols_ SOAP vs. REST vs. JSON-RPC vs. gRPC vs. GraphQL vs. Thrift]: https://www.mertech.com/blog/know-your-api-protocols
[format_png]: https://img-blog.csdnimg.cn/img_convert/3fb5b0f0a019c6471f5d0b1e5b454cd1.webp?x-oss-process=image/format,png