简体中文
GraphQL 与 REST API
探索 GraphQL 和 REST API 的关键区别，它们的优点，以及在何时使用它们以实现最佳的网络开发。
Darcy Ye
Developer
Developer
Simeng
Developer
Developer
探索 GraphQL 和 REST API 的关键区别，它们的优点，以及在何时使用它们以实现最佳的网络开发。
你曾经参与过 Web 应用开发项目吗？如果有，那么你可能已经遇到过"GraphQL"这个术语。但它到底是什么意思？它是在服务器端还是客户端配置中使用的呢？此外，什么时候 GraphQL 集成比其他选择更合适？在本文中，我们将引导你解答这些问题。
作为软件组件之间通过互联网进行数据传输的沟通渠道，API 在现代网络服务架构中扮演着不可或缺的角色，就像氧气一样。API 技术如 SOAP（网络服务消息协议）、REST（架构风格）和 GraphQL（查询语言和工具）通过支持不同服务之间的集成和数据交换，使得软件开发更为便利和灵活。
尽管有众多类型的 API，近年来的辩论主要集中在两大范式上：REST（表述性状态传递）和 GraphQL。两者都提供了一系列的优点，并在全球网络项目中被使用。然而，在如何管理数据通信上，它们存在显著差异。
REST 是一种在 21 世纪初期开发的结构化架构风格，用于构建跨网络的超媒体应用，旨在采用无状态、可缓存的通信协议，在客户端和服务器之间通信。REST API（也称为 RESTful API）是 REST 架构的驱动者。
REST API 使用统一资源标识符（URI）来寻址资源。REST API 通过使用不同的端点对网络资源执行 CRUD（创建、读取、更新和删除）操作。它依赖于预定义的数据格式（称为媒体类型或 MIME 类型）来确定它们向客户端提供的资源的形式和大小。最常见的格式是 JSON 和 XML（有时是 HTML 或纯文本）。
在客户端请求一个资源后，服务器处理查询并返回与该资源相关的所有数据。响应包含 HTTP 响应代码，例如"200 OK"（成功的 REST 请求）和"404 Not Found"（不存在的资源）。
REST API 依靠预定义的端点通过 HTTP 暴露资源。每个端点表示一个资源，例如用户或帖子，并由一个唯一的 URL 标识。REST 操作与标准的 HTTP 方法相绑定，如 GET、POST、PUT 和 DELETE，它们分别对应于检索、创建、更新和删除数据。
例如，请求GET /users检索完整的用户列表，而GET /users/123获取由其 ID 标识的特定用户的详细信息。如果你还需要访问相关数据，如用户的组织和组织角色，你需要向GET /users/123/organizations发出额外的调用。
REST 遵循一种以资源为中心的方法，专注于访问和操作离散资源。
GraphQL 既是一种 API 类型（或查询语言）也是一种响应这些查询的运行时引擎。它提供了一个简化的 API，特别适合于移动应用程序和需要特定数据子集实现的复杂架构。
使用 GraphQL，开发者可以指定他们希望从 API 获取的数据。它还允许按需数据检索，而不是一次性获取所有数据，立即应用更改，并将第三方数据源集成到应用程序中。
应用程序可以使用 GraphQL 查询来调用 GraphQL 服务。这些查询返回客户端请求的确切数据元素。这节省了多次 API 调用、网络带宽和后期处理。它是一个高效的解决方案，适用于靠近消费者设备（如平板电脑和手机）的数据中心化 API。
相比之下，GraphQL 采用了一种基于查询的方法。GraphQL 不依赖预定义的端点，而是暴露一个接受结构化查询的单一端点。客户端可以使用查询语言精确地指定他们需要的数据。
因此，一个完整的 GraphQL 实现必须有两个部分：架构和解析器。
架构定义了可以通过 GraphQL 查询检索的数据类型及其字段：
例如，假设你有以下架构：
客户端可以使用以下查询来获取用户的名称、电子邮件、组织及其角色：
此查询不仅仅获取请求的字段（电子邮件和组织），还在单个请求中检索相关数据（角色）。
GraphQL 解析器是 GraphQL 服务器中的一个关键组件，决定了如何获取或计算客户端在 GraphQL 查询中请求的数据。当客户端发送查询时，查询中的每个字段都匹配到一个解析器，其中包含检索或计算该字段数据的逻辑。
在上面的例子中，架构的解析器如下所示：
解析器有两种类型：根解析器和字段解析器。
GraphQL 支持三种类型的操作：查询、变更和订阅。
Query：用于读取数据。Mutation：用于写入数据，包括添加、修改和删除操作。Subscription：用于请求数据的持久连接，允许客户端声明其感兴趣的事件类型和应返回的数据。GraphQL 和 REST API 是用于在不同网络服务之间交换数据的工具，但由于它们采取了不同的方法来解决问题，因此它们之间存在以下主要区别：
REST API 通常会过度获取或不足获取数据，因为端点返回固定的响应。GraphQL 通过让客户端请求确切需要的数据解决了这个问题，从而减少了不必要的数据传输。这使得 GraphQL 非常适合具有复杂数据需求的应用程序，例如移动或低带宽环境。
想象上面的例子，在那里你需要获取用户的静态数据、分配给用户的组织和组织角色。使用 REST API，你需要向不同的端点发出多个请求来获取所有数据。然而，使用 GraphQL，你可以在一个请求中获取所有的数据。
REST 基于端点的结构简单明了，适用于具有标准 CRUD 操作的简单应用。这是因为 REST API 设计为以资源为中心，每个端点代表一个特定的资源。这种方法的主要限制在于无法快速迭代和满足客户端需求的变化。对于客户端的每一个更改，服务器都必须更新以适应新的需求，要么通过添加新端点，要么通过更新现有端点。这通常会导致大量的冗余端点和复杂的 API 版本管理。
而 GraphQL 更加灵活，允许客户端仅请求所需的数据。这种灵活性在客户端需求经常变化时尤其有用，因为它消除了修改服务器端 API 实现的需要。客户端可以请求新的字段或嵌套数据，而无需更改服务器。
即使 GraphQL 在数据获取方面更加高效和灵活，它也有一些缺点。主要问题之一是缓存。
REST API 拥有成熟的生态系统。由于其无状态和标准化的特性，很容易在服务器和客户端级别缓存响应。这可以显著减少向服务器发出的请求数量并提高性能。
然而，由于 GraphQL 的灵活性，许多可用于 REST API 的缓存技术对于 GraphQL 并不适用。需要根据特定用例在客户端处理缓存，这给客户端开发带来了额外的工作量。
| 名称 | 优点 | 缺点 |
|---|---|---|
| REST API | - 简单且被广泛采用，拥有广泛的工具和社区支持。 - 结构清晰，初学者易于理解。 - 通过 HTTP 标准支持内置缓存。 | - 过度获取或不足获取数据 - 变更通常需要创建新版本，增加了维护开销。 |
| GraphQL | - 精确的数据获取提高了性能和效率。 - 架构进化减少了版本管理的需求。 - 强大的工具，如自省和类型检查，增强了开发体验。 | - 与 REST 相比，设置更复杂，学习曲线更陡峭。 - 需要定制缓存解决方案，因为它不依赖 HTTP 缓存。 - 单一端点设计可能使调试和监控复杂化。 |
尽管作为新贵的 GraphQL 在近年来获得了强劲的势头，但 REST API 由于其原子设计和严谨性，仍然保持着长久的重要性。
REST 和 GraphQL 满足不同的需求，并在不同的场景中表现出色。REST 的简单性使其成为简单应用程序和微服务的完美选择。GraphQL 在需要灵活和高效数据检索的场景中脱颖而出，特别是在具有多样化客户端或数据之间有复杂关系的应用程序中。选择两者取决于项目的具体需求、团队的专业知识和长期可扩展性需求。