GraphQL 与 REST 应用程序接口：有什么区别？

应用程序接口 (API) 作为软件组件交互和数据在互联网上流动的通道，是当代网络服务的命脉。SOAP（一种网络服务消息传输协议）、REST（一种架构风格）和 GraphQL （一种编程语言和工具）等应用程序接口技术可实现第三方数据和服务集成，从而简化软件开发。应用程序接口还能让公司为员工、业务合作伙伴和用户提供安全的服务功能和数据交换。

尽管应用程序接口类型众多，但近年来关于两种主要范式的争论占据了主流：REST（表述性状态转移）和 GraphQL。二者都具有一系列优点，因此被广泛应用于全球各地的网络项目。然而，它们在管理数据流量的方式上却截然不同。我们将在此剖析这些差异，并讨论企业如何使用 REST 和 GraphQL 应用程序接口来优化其网络。

要对 REST 和 GraphQL 应用程序接口进行比较，有必要分别了解这两种应用程序接口。

REST

REST 开发于 2000 年代初期，是一种用于网络超媒体应用程序的结构化架构风格，旨在使用无状态、客户端/服务器、可缓存的通信协议。REST 应用程序接口也称为 RESTful 应用程序接口，是 REST 架构的驱动力。

REST 应用程序接口使用唯一资源标识符 (URI) 对资源进行寻址。REST 应用程序接口的工作原理是让不同的端点对网络资源执行 CRUD（“创建”、“读取”、“更新”和“删除”）操作。它们依靠一种预定义的数据格式（称为媒体类型或 MIME 类型）来确定向客户端提供的资源的形状和大小。最常见的格式是 JSON 和 XML（有时是 HTML 或纯文本）。

客户端请求资源时，服务器会处理查询，并返回与该资源相关的所有数据。响应包括 HTTP 响应代码，例如“200 OK”（REST 请求成功）和“404 Not Found”（资源不存在）。

GraphQL

GraphQL 是一种查询语言和 API 运行时，由 Facebook 于 2012 年内部开发，然后在 2015 年开源。

GraphQL 由用 GraphQL 架构定义语言编写的 API 架构定义。每个模式都规定了用户可以查询或修改的数据类型，以及这些类型之间的关系。解析器支持模式中的每个字段。解析器提供将 GraphQL 查询、更改和订阅转化为数据的指令，并从数据库、云服务和其他来源检索数据。解析器还提供数据格式规范，使系统能够拼接来自不同来源的数据。

REST 通常使用多个端点来获取数据和执行网络操作，而 GraphQL 则不同，它通过使用单个端点来公开数据模型，客户端可通过该端点发送 GraphQL 请求，而不管他们请求什么。然后，应用程序接口访问资源属性，并跟踪资源之间的引用，通过对 GraphQL 服务器的单次查询，为客户端提供所需的全部数据。

GraphQL 和 REST 应用程序接口都是基于资源的数据交换，使用 HTTP 方法（如 PUT 和 GET 请求）来决定客户端可以执行哪些操作。然而，它们之间存在着关键的差异，这不仅解释了 GraphQL 的普及，也解释了为什么 RESTful 系统具有如此持久的生命力。

GraphQL 为 REST 提供了高效、更灵活的补充； GraphQL 应用程序接口通常被视为 RESTful 环境的升级版，尤其是考虑到它们能够促进前端和后端团队之间的协作能力。GraphQL 为组织的应用程序接口之旅提供了合乎逻辑的后续步骤，有助于解决 REST 经常遇到的问题。

然而，REST 长期以来一直是应用程序接口架构的标准，许多开发人员和架构师仍然依赖 RESTful 配置来管理他们的 IT 网络。因此，了解两者之间的区别对于任何组织的 IT 管理策略来说都是不可或缺的。

REST 和 GraphQL 应用程序接口在管理方式上有所不同：

数据检索

由于 REST 依赖于多个端点和无状态交互——在这种交互中，每个应用程序接口请求都会作为一个新的查询来处理，独立于任何其他查询——因此客户端会收到与资源相关的每一条数据。如果客户端只需要数据的子集，它仍然会接收所有数据（过度获取）。而且，如果客户端需要跨越多个资源的数据，RESTful 系统通常会让客户端分别查询每种资源，以弥补初始请求中数据检索不足（抓取不足）的问题。GraphQL 应用程序接口使用单个 GraphQL 端点，在单个请求的单次往返中为客户提供精确、全面的数据响应，从而消除了过度获取和抓取不足的问题。

版本控制

在 REST 架构中，团队必须使用版本应用程序接口来修改数据结构，并防止系统出错和最终用户的服务中断。换句话说，开发人员每次进行更改时都必须创建一个新的端点，这样就会创建多个应用程序接口版本，并可能使维护工作复杂化。GraphQL 减少了对版本管理的需求，因为客户端可以在查询中指定他们的数据需求。向服务器添加新字段不会影响不需要这些字段的客户端。相反，如果字段已被弃用，客户端可以继续请求这些字段，直到查询更新为止。

错误处理

REST 应用程序接口应使用 HTTP 状态代码来表示请求的状态或成功与否，每个状态代码都有特定的含义。成功的 HTTP 请求会返回 200 状态代码，而客户端错误可能会返回 400 状态代码，服务器错误可能会返回 500 状态代码。

乍一看，这种状态报告方法似乎更直接，但 HTTP 状态代码对网络用户的作用往往大于对应用程序接口本身的作用，尤其是在出错的情况下。REST 没有关于错误的规范，因此应用程序接口错误可能显示为传输错误，或者根本不显示状态代码。这种动态变化会迫使工作人员阅读状态文档，以了解错误的含义，甚至是错误在基础架构内的传播方式。

在使用 GraphQL 应用程序接口时，无论是否出错，每次请求都会返回 200 OK 状态代码，因为错误不通过 HTTP 状态代码进行传达（传输错误除外）。相反，系统会在响应正文中与数据一起传递错误信息，因此客户端必须通过解析数据有效载荷来确定请求是否成功。

尽管如此，GraphQL 确实有错误规范，因此更容易将应用程序接口错误与传输错误区分开来。错误的确切性质会显示在响应正文中的“错误”条目中，这使得 GraphQL 应用程序接口更适合于构建。

实时数据

REST 本身不支持实时更新。如果应用程序需要实时功能，开发人员通常必须采用长时间轮询（客户端反复轮询服务器以获取新数据）和服务器发送事件等技术，这会增加应用程序的复杂性。

然而，GraphQL 本身支持通过订阅进行实时更新。订阅可以保持与服务器的稳定连接，使服务器能够在特定事件发生时向客户端推送更新。

工具和环境

REST 环境非常完善，为开发人员提供了广泛的工具、库和框架。然而，使用 REST 应用程序接口需要团队浏览多个端点，并了解每个应用程序接口的独特约定和模式。

GraphQL 应用程序接口相对较新，但 GraphQL 环境自推出以来已取得巨大发展，为服务器和客户端开发提供了各种可用的工具和库。GraphiQL 和 GraphQL Playground 等工具为探索和测试 GraphQL 应用程序接口提供了功能强大的浏览器内集成开发环境（IDE）。此外，GraphQL 对代码生成具有强大的支持，可以简化客户端开发。

缓存

REST 应用程序接口依赖于 eTags 和最后修改标头等机制来缓存应用程序接口调用。这些缓存策略虽然有效，但实施起来可能比较复杂，而且不一定适合所有用例。

由于查询的动态特性，GraphQL 应用程序接口的缓存可能更具挑战性。然而，部署持久化查询、响应缓存和服务器端缓存可以缓解这些挑战，并简化 GraphQL 架构的更广泛的缓存工作。

REST 应用程序接口和 GraphQL 应用程序接口本身并无优劣之分；它们是适合不同任务的不同工具。

REST 通常更易于实现，当首选具有严格访问控制的简单、可缓存的通信协议时，REST 可能是一个不错的选择（例如 Shopify 和 GitHub 等面向公众的电子商务网站）。考虑到抓取不足和过度获取的风险，REST 应用程序接口最适合用于以下情况：

• 使用规模较小、数据配置文件较为简单的应用程序的企业
• 没有复杂数据查询需求的企业
• 大多数客户群以类似方式使用数据和操作的企业

GraphQL 应用程序接口可实现更灵活、更高效的数据获取从而提高系统性能并提高开发人员的易用性。这些特征使得 GraphQL 在复杂环境中快速变化的前端需求中构建应用程序接口特别有用。其中包括：

• 带宽有限且希望限制通话和回复量的企业
• 希望在一个端点整合数据点的企业
• 客户要求差异很大的企业

尽管 GraphQL 和 REST API 使用不同的方法，但它们都有可能大大提高网络可扩展性和服务器性能。

无论您选择部署 REST 应用程序接口还是GraphQL 应用程序接口，还是两者的某种组合，您的企业都可以从广泛的潜在应用中获益，包括使用各种编程语言（如 JavaScript）的实施以及与微服务和无服务器架构的集成。 利用 IBM API Connect，您可以使用这两种应用程序接口类型来优化您的 IT 基础设施。

IBM API Connect 是一款全生命周期应用程序接口管理解决方案，可以帮助您创建、管理、保护应用程序接口，实现应用程序接口的社交化及其经济效益，并推动跨数据中心和云环境的数字化转型。这意味着，企业和客户都可以为数字应用程序提供动力，并实时推动创新。

企业可以利用 API Connect 帮助确保自己在应用程序接口管理方面的领先地位，这在计算领域将是无价之宝，因为随着时间的推移，计算领域将变得越来越大、越来越复杂、竞争越来越激烈。