作为软件组件交互和数据在互联网上流动的渠道，API 是当代 Web 服务的命脉。 SOAP（一种 Web 服务消息传递协议）、REST（一种架构风格）和 GraphQL（一种编程语言和工具）等 API 技术通过支持第三方数据和服务集成来简化软件开发。 API 还使公司能够向员工、业务合作伙伴和用户提供安全的服务功能和数据交换。
尽管 API 类型很多，但近年来关于两种主要范式的争论占据了主导地位：REST（表征状态转移）和 GraphQL。 两者都具有一系列优势，因此被部署用于全球的网络项目。 然而，它们在管理数据流量的方式上存在显着差异。 在这里，我们剖析这些差异并讨论企业如何使用 REST 和 GraphQL API 来优化其网络。
什么是 REST 和 GraphQL API？
为了比较两者，需要分别了解 REST 和 GraphQL API。
休息
REST 开发于 2000 年代初期，是一种用于网络超媒体应用程序的结构化架构风格，旨在使用无状态、客户端/服务器、可缓存通信协议。 REST API，也称为 RESTful API，是 REST 架构的驱动程序。
REST API 使用唯一资源标识符 (URI) 来寻址资源。 REST API 的工作原理是让不同的端点对网络资源执行 CRUD（“创建”、“读取”、“更新”和“删除”）操作。 它们依靠预定义的数据格式（称为媒体类型或 MIME 类型）来确定向客户端提供的资源的形状和大小。 最常见的格式是 JSON 和 XML（有时是 HTML 或纯文本）。
当客户端请求资源时，服务器处理查询并返回与该资源关联的所有数据。 响应包括 HTTP 响应代码，例如“200 OK”（对于成功的 REST 请求）和“404 Not Found”（对于不存在的资源）。
GraphQL
GraphQL 是 Facebook 于 2012 年内部开发的一种查询语言和 API 运行时，并于 2015 年开源。
GraphQL 由以 GraphQL 模式定义语言编写的 API 模式定义。 每个模式指定用户可以查询或修改的数据类型以及类型之间的关系。 解析器支持模式中的每个字段。 解析器提供将 GraphQL 查询、突变和订阅转换为数据的指令，并从数据库、云服务和其他来源检索数据。 解析器还提供数据格式规范，并使系统能够将来自不同来源的数据拼接在一起。
与 REST（通常使用多个端点来获取数据并执行网络操作）不同，GraphQL 通过使用单个端点来公开数据模型，客户端通过该端点发送 GraphQL 请求，无论他们要求什么。 然后，API 访问资源属性（并跟踪资源之间的引用），以通过对 GraphQL 服务器的单个查询获取客户端所需的所有数据。
GraphQL 和 REST API 都是基于资源的数据交换，它们使用 HTTP 方法（如 PUT 和 GET 请求）来指示客户端可以执行哪些操作。 然而，它们之间存在关键差异，这不仅解释了 GraphQL 的激增，也解释了为什么 RESTful 系统具有如此持久的力量。
GraphQL 和 REST API 之间的差异
GraphQL 为 REST 提供了高效、更灵活的补充； GraphQL API 通常被视为 RESTful 环境的升级，特别是考虑到它们能够促进前端和后端团队之间的协作。 GraphQL 为组织的 API 之旅提供了合乎逻辑的下一步，帮助解决 REST 中经常遇到的问题。
然而，REST 长期以来一直是 API 架构的标准，许多开发人员和架构师仍然依赖 RESTful 配置来管理其 IT 网络。 因此，了解两者之间的区别对于任何组织的 IT 管理策略都是不可或缺的。
REST 和 GraphQL API 的不同之处在于管理方式：
数据检索
由于 REST 依赖于多个端点和无状态交互（其中每个 API 请求都作为新查询进行处理，独立于任何其他请求），因此客户端会收到与资源关联的每条数据。 如果客户端只需要数据的子集，它仍然会收到所有数据（过度获取）。 如果客户端需要跨多个资源的数据，RESTful 系统通常会让客户端单独查询每个资源，以弥补初始请求中数据检索不足的情况（获取不足）。 GraphQL API 使用单个 GraphQL 端点在单个请求的单次往返中为客户端提供精确、全面的数据响应，从而消除过度获取和获取不足的问题。
版本控制
在 REST 架构中，团队必须对 API 进行版本控制以修改数据结构，并防止最终用户出现系统错误和服务中断。 换句话说，开发人员每次进行更改时都必须创建一个新端点，从而创建多个 API 版本并可能使维护变得复杂。 GraphQL 减少了版本控制的需求，因为客户端可以在查询中指定其数据要求。 向服务器添加新字段不会影响不需要这些字段的客户端。 相反，如果字段已弃用，客户端可以继续请求它们，直到更新查询。
错误处理
REST API 应该 使用 HTTP 状态代码来指示请求的状态或成功，每个状态代码都有特定的含义。 成功的 HTTP 请求会返回 200 状态代码，而客户端错误可能会返回 400 状态代码，服务器错误可能会返回 500 状态代码。
乍一看，这种状态报告方法似乎更简单，但 HTTP 状态代码对 Web 用户而言通常比对 API 本身更有用，尤其是在出现错误的情况下。 REST 没有错误规范，因此 API 错误可能会显示为传输错误，或者根本不会与状态代码一起出现。 这种动态会迫使人员仔细阅读状态文档，以了解错误的含义，甚至错误在基础设施内是如何传达的。
使用 GraphQL API，每个请求（无论是否导致错误）都会返回 200 OK 状态代码，因为错误不会使用 HTTP 状态代码进行传达（传输错误除外）。 相反，系统会在响应正文中与数据一起传达错误，因此客户端必须解析数据负载以确定请求是否成功。
也就是说，GraphQL 确实有错误规范，因此 API 错误更容易与传输错误区分开。 错误的确切性质出现在响应正文中的“错误”条目中，这可以使 GraphQL API 更适合构建。
实时数据
REST 没有内置的实时更新支持。 如果应用程序需要实时功能，开发人员通常必须实现长轮询（客户端重复轮询服务器以获取新数据）和服务器发送事件等技术，这会增加应用程序的复杂性。
但是，GraphQL 内置了通过订阅进行实时更新的支持。 订阅保持与服务器的稳定连接，允许服务器在发生特定事件时将更新推送到客户端。
工具与环境
REST 环境已经完善，为开发人员提供了广泛的工具、库和框架。 尽管如此，使用 REST API 需要团队导航多个端点并了解每个 API 的独特约定和模式。
GraphQL API 相对较新，但 GraphQL 环境自推出以来已经取得了巨大的发展，提供了可用于服务器和客户端开发的各种工具和库。 GraphQL 和 GraphQL Playground 等工具提供了强大的浏览器内集成开发环境 (IDE)，用于探索和测试 GraphQL API。 此外，GraphQL 对代码生成有强大的支持，可以简化客户端开发。
缓存
REST API 依赖 eTags 和上次修改标头等机制来缓存 API 调用。 这些缓存策略虽然有效，但实施起来可能很复杂，并且可能并不适合所有用例。
由于查询的动态特性，GraphQL API 的缓存可能更具挑战性。 然而，部署持久化查询、响应缓存和服务器端缓存可以缓解这些挑战，并简化 GraphQL 架构中更广泛的缓存工作。
何时使用 GraphQL 和 REST API
REST 和 GraphQL API 本质上都不是优越的； 它们是适合不同任务的不同工具。
REST 通常更容易实现，并且当首选具有严格访问控制的直接、可缓存通信协议时（例如 Shopify 和 GitHub 等面向公众的电子商务网站），REST 可能是一个不错的选择。 考虑到获取不足和过度获取的风险，REST API 最适合：
- 使用较小的应用程序和更简单的数据配置文件的企业
- 无复杂数据查询需求的企业
- 大多数客户群以类似方式使用数据和操作的企业
GraphQL API 可实现更灵活、高效的数据获取，从而提高系统性能和开发人员的易用性。 这些功能使得 GraphQL 对于在前端需求快速变化的复杂环境中构建 API 特别有用。 这包括：
- 带宽有限、希望限制呼叫和响应的企业
- 希望在一个端点合并数据点的企业
- 客户要求差异很大的企业
尽管它们使用不同的方法，但 GraphQL 和 REST API 都具有极大增强网络可扩展性和服务器性能的潜力。
使用 IBM API Connect 控制您的 API 环境
无论您选择部署 REST 还是 GraphQL API（或者两者的某种组合），您的企业都可以从广泛的潜在应用程序中受益，包括各种编程语言（如 JavaScript）的实现以及与微服务和无服务器架构的集成。 借助 IBM API Connect，您可以使用这两种 API 类型来优化您的 IT 基础架构。
IBM API Connect 是一个全生命周期 API 管理解决方案，可帮助您创建、管理、保护、社交化 API 并使其货币化，并促进跨数据中心和云环境的数字化转型。 这意味着企业和客户都可以为数字应用程序提供支持并实时刺激创新。
借助 API Connect，企业可以帮助确保他们在 API 管理方面处于领先地位，这在随着时间的推移将变得更大、更复杂和更具竞争力的计算环境中将证明是无价的。
探索 IBM API Connect 订阅 AI 主题更新
本文是否有帮助？
是的不
