API 是现代软件开发过程中最重要的组成部分，可帮助应用程序和服务交流和传输关键信息。

然而，随着该领域的进步，现在有多种选择可供选择：REST、SOAP、GraphQL 或 gRPC。这意味着无论您是应用程序架构师还是后端开发人员，您都必须了解哪些 API 最适合特定应用程序。

每种 API 类型都有其独特的体系结构，这些体系结构是根据时代的需要而发展的。而且，随着技术的发展以及我们与技术的关系发生了变化，我们已经看到 API 的出现是为了弥补新的差距并服务于新的用途。

在本文中，我们将了解 SOAP、REST、GraphQL 和 gRPC API 如何相互比较，让您了解它们的优缺点、常见用例以及在为您选择最佳 API 时的其他注意事项您的需求。

REST API

REpresentational State Transfer (REST) 是一种软件架构风格，用于开发 API 以提供简单、统一的接口。这些可用于使数据、内容、算法、媒体和其他数字资源可通过 Web URL 访问，从而允许通过 Web、移动和设备应用程序使用它们。它们允许以 JSON 和 XML 等简单格式进行数据交换。

REST API 遵守以下六个特定的架构约束：

1. 统一的界面
2. 完全无国籍
3. 本机缓存
4. 客户端-服务器架构
5. 分层系统
6. 向客户端提供可执行代码的能力

下面是 REST API 消息的示例：

{"car": {"vin": "KNDJT2A23A7703818","make": "kia","model": "soul","year": 2010,"links": {"service": "/cars/KNDJT2A23A7703818/service","sell": "/cars/KNDJT2A23A7703818/sell","clean": "/cars/KNDJT2A23A7703818/sell"}}
}

优点

• REST API 基于 HTTP 协议，这意味着它们与格式无关，允许您使用 XML、JSON、HTML 和其他格式。这使得 REST API 快速且轻量级，这对于移动应用程序开发、物联网设备和其他应用程序至关重要。

• REST API 可以很容易地从 URL 中发现，因此，开发人员可以很容易地测试它们并与他们的应用程序集成。

• REST API 是无状态的，因此，它们使用起来非常灵活，并且根据用例具有高度可扩展性。

• 这些 API 可以用 Python、JavaScript (Node.js)、Ruby、C# 和各种其他语言开发，使大多数开发人员更容易访问它们。

缺点

• RESTful API 的一个缺点是失去了维护状态的能力，例如在会话中。对于新手开发人员来说，使用它也可能更具挑战性。

• 因此，REST 确实强加了任何安全性，它适用于公共 URL，但不适用于客户端和服务器之间的机密数据交换。

• 通信结构上没有约束力的合同。结果，在执行时，有很多来回，这可能会导致不必要的挫折和瓶颈。

您可以使用 API Tester创建并发送您的第一个 REST API 请求，并亲眼看看它是如何工作的。

SOAP API

简单对象访问协议 (SOAP) 是一种协议，用于在客户端和基于 Internet 的操作或服务之间共享以可扩展标记语言 (XML) 编码的信息。它可以与各种传输协议一起使用，例如 HTTP、FTP、SMTP 等。

SOAP 通常与 Web 服务描述语言 (WSDL) 结合使用。WSDL 的重要性在于它允许开发人员和机器分析支持 SOAP 的 Web 服务，以了解网络上信息交换的细微差别。此外，WSDL 解释了如何格式化所提供服务支持的 SOAP 请求和应答消息。

SOAP 用于需要高安全性和复杂事务的企业级 Web 服务。SOAP 经常用于金融服务、支付网关、CRM 软件、身份管理和电话服务的 API。

SOAP 消息具有层次结构，以作为根元素。可以将三个子元素添加到根元素。这些是子元素、和。

下面是 SOAP 消息的示例：

POST /Quotation HTTP/1.0
Host: www.xyz.org
Content-Type: text/xml; charset = utf-8
Content-Length: nnn
MiscroSoft

优点

• 由于标准化格式，SOAP 完全与编程语言和处理平台无关。
• SOAP API 带有内置的本机错误处理功能，可帮助开发人员快速识别和解决问题。
• SOAP API 最适合来回传输敏感数据，例如财务数据，因为它的标准化允许在所有 API 中以代码形式强加特定合同。
• SOAP 支持有状态操作，并且可以使用构建在基本 XML 和 SOAP 标准之上的 WS-*（Web 服务）规范来实现。

缺点

• 由于 SOAP 只能将消息作为 XML 文件发送，因此 SOAP API 的性能会降低，因为 XML 是一种比 JSON 更冗长的格式。
• 对服务器的 SOAP API 请求会消耗更多带宽，并且需要更长的时间来处理请求并将结果返回给客户端。
• SOAP 客户端-服务器通信基于 WSDL（Web 服务描述语言）契约，意味着紧密连接。因此，它不适合松散连接的应用程序，因为您无法避免客户端和服务器之间的契约。
• SOAP 的学习曲线也更陡峭，更难开发，并且无法在 Web 浏览器中进行测试（与 REST 不同）。SOAP 要求您在 WSDL 中构建契约​​、建立客户端存根、遵守严格的要求等等。结果，作为程序员，您在选择上的灵活性会降低。

API Tester 支持向 SOAP API 发送请求，并允许您轻松快速地测试 API。

GraphQL API

当 Facebook 创建GraphQL时，他们需要一个强大的数据获取 API，该 API 可以执行 Facebook 的所有任务，同时对他们的产品开发人员而言简单明了且易于学习和使用。GraphQL 的创建是为了重建 Facebook 的原生移动应用程序。

GraphQL 是一种查询语言。它以字符串的形式返回查询，然后将其提交给服务器。服务器处理查询并以 JSON 格式将响应传递给客户端。

GraphQL 是一种强类型语言，其中 GraphQL 查询的每个级别对应不同的类型，并且每种类型代表一组不同的可访问字段。因此，它类似于 SQL，因为它在执行查询之前提供信息性错误警告，因此得名。

GraphQL 具有层次结构，其中对象之间的关系以图形方式定义。每个对象类型都表示此上下文中的一个组件，并且从一个对象类型到另一个对象类型的每个相关字段都表示一个包装另一个组件的组件。

一个简单的 GraphQL 请求如下所示：

{me {namefriends {name}}
}

当从单体后端应用程序迁移到微服务设计时，GraphQL API 可以通过将它们集成到单个 GraphQL 模式中来帮助我们管理众多微服务之间的通信。

优点

• GraphQL 比其他通信 API 快得多，因为它允许您通过仅选择您希望查询的数据来缩小您的请求查询范围。因此，它解决了所有过度获取和获取不足的问题。

• 使用 GraphQL 的 API，我们可以集成众多平台。它将它们聚集在一起，同时掩盖了它们的复杂性。GraphQL 服务器还用于从现有系统中检索数据并将其打包为 GraphQL 响应格式。这对于规模庞大且难以管理的遗留基础设施或第三方 API 尤其有用。

• 当我们向服务器发送 GraphQL 查询时，服务器会以一种简单、安全且可预测的格式进行响应。因此，它使您可以更轻松地根据需要构建自定义查询。这使得 GraphQL 非常易于学习和使用。

• 在更高的组件级别，我们可以共享许多查询中使用的 GraphQL 字段以供重用。此功能称为片段，它允许您在保持相同模式字段的同时获取不同的数据。

• 由于 GraphQL 中的结果集或返回数据对于客户端的查询具有高度特殊性，因此服务器可以非常直接且容易地概括它。当我们向服务器添加新的产品功能或字段时，它对旧客户端没有影响。您可以继续使用旧服务器而不用担心，因为服务器字段可以被弃用但仍然可以运行。此兼容过程不需要使用不断增加的版本号。如您所见，Facebook 在其所有应用程序中使用相同版本的 GraphQL API。

缺点

• 一个缺点是查询总是返回 HTTP 状态代码 200，无论它们是否成功。如果您的查询失败，您返回的 JSON 将包含一个包含错误消息和堆栈跟踪的顶级错误键。这会使错误处理变得更加困难，并增加监视等事情的复杂性。
• 使用 GraphQL 实现简化缓存比在 REST 中实现更复杂。
• 速率限制是 GraphQL 的另一个问题。在 REST API 中，您可以轻松地写下“我们一天只接受这么多请求”，但在 GraphQL 中，这种语句更难传达。
• 如果没有大量的培训和经验，很难掌握 GraphQL。

GitHub 的 GraphQL API是最常用的免费开发者 API。在几分钟内在 API Tester 中创建并运行 GraphQL 请求，然后开始探索更多！

gRPC

gRPC 远程过程调用(gRPC) 是一种跨平台、开源、基于契约的通信协议，它通过向外部客户端提供一组功能来简化和控制服务间通信。

开头的'g'表示这是谷歌在2015年创建的最先进的版本。一方面，用户将选择一个远程进程来运行，序列化所需的参数，然后将任何附加信息附加到消息中。然后将其传输到服务器，服务器与其他应用程序通信，解码消息并执行操作。然后给原始用户一个结果。

优点

• 它简单明了，GET 用于获取信息，POST 用于其他所有内容。
• 功能添加简单，对于轻量级有效载荷，整体性能非常出色。因此，由于定义任何类型的功能的灵活性，它可以无限地定制。

缺点

• gRPC 与底层系统的紧密连接这一事实限制了它在许多情况下的可重用性，这是它的不足之处。此外，API 和实际系统功能之间不存在抽象层，这会引发安全问题。

如何选择适合您使用的 API？

从上面的讨论中您可能会猜到，没有“最佳”API 类型，每种 API 类型都有其独特的特性，使它们非常适合特定的应用程序。然而，问题仍然存在——如何找到最适合你的那一款？

以下是一些可以帮助您确定的问题：

• 您想使用哪种编程语言？
• 您将在哪种环境中开发？
• 这个 API 最重要的功能是什么？
• 你对员工有什么技能？你可以获得什么技能？
• 你为这个项目预留了哪些资源？

请记住，您始终可以使用一种或两种类型运行简单的概念验证来测试它们的工作方式。您还可以使用API Tester，这是一款易于使用的移动应用程序，可帮助您在手机上测试任何 API。

结论

我们希望这篇博文有助于区分最流行的 API 类型。每个都有一个目的，当您预先进行深思熟虑和深思熟虑的选择时，您就可以设计出一个不仅有效而且资源敏感的 API。