GraphQL vs. REST：为什么你的下一个 API 可能更倾向于 GraphQL

Source: Dev.to

介绍

嗨，Dev.to 社区！

我们都有过这样的经历：你正在构建一个新应用，正需要决定前端如何与后端通信。多年来，REST 一直是 API 设计中无可争议的王者，这并非没有原因——它稳健、被广泛理解且极其灵活。但近年来，一个名为 GraphQL 的新竞争者崭露头角。

虽然 REST 不会消失，GraphQL 却提供了一些引人注目的优势，正让开发者认真重新审视自己的 API 策略。让我们深入探讨一下，为什么 GraphQL 可能是你下一个项目的更佳选择。

Source: …

REST 的问题（有时）

别误会，我很喜欢 REST。它在很多使用场景下都很棒。然而，随着应用变得更复杂、用户界面更加动态，REST 在两个关键方面会显露出局限性：

• 过度获取
  想象一下，你需要在个人资料页显示用户的姓名和电子邮件。使用 REST 时，你可能会请求 /users/:id 这样的端点。但该端点可能会返回大量你当前不需要的数据——地址、订单历史、偏好设置等。所有这些额外数据都要通过网络传输，浪费带宽并可能导致应用变慢。

• 不足获取
  相反，如果你需要显示用户的姓名、最近的 3 条帖子以及这些帖子的评论，你可能会发起多个请求：先请求 /users/:id，再请求 /users/:id/posts，然后对每条帖子请求 /posts/:id/comments。这种 “n+1” 问题会导致多次往返服务器，增加延迟。

• 版本管理和多端点
  随着应用的演进，API 也会随之变化。你可能会先创建 /v1/users，随后为了处理变更而创建 /v2/users，从而导致一大堆端点，难以管理和文档化。

进入 GraphQL：一种更好的获取数据方式

GraphQL 由 Facebook 开发，并不是数据库技术；它是一种用于 API 的查询语言，以及一个使用现有数据来满足这些查询的运行时。核心理念简单而强大：客户端明确指定它需要的具体数据。

GraphQL 的主要优势

单一端点，精准数据获取

与众多 REST 端点不同，GraphQL API 通常只暴露一个端点（例如 /graphql）。客户端随后发送一个查询，明确描述它需要的具体数据，服务器只返回这些数据。

query GetUserAndPosts($id: ID!) {
  user(id: $id) {
    name
    email
    posts {
      title
      content
      comments {
        text
      }
    }
  }
}

服务器接收该查询后返回一个与其结构相匹配的 JSON 对象。没有过度获取，也没有不足获取，仅在一次请求中实现高效的数据检索！

减少网络请求

因为可以在单个查询中请求多个资源（例如用户、其帖子以及这些帖子的评论），所以可以大幅度减少客户端需要发起的 HTTP 请求次数。这对移动应用或高延迟环境来说是一个颠覆性的改进。

强类型模式

GraphQL API 由模式（schema）定义，模式充当客户端与服务器之间的契约。该模式列出所有可用的数据类型和操作。工具可以基于此模式实现：

• 开发环境中的自动补全和校验。
• 自动生成文档，确保 API 文档始终保持最新。
• 类型安全，在运行时之前捕获错误。

基本无需版本管理

通过精心设计的 GraphQL 模式，你可以添加新字段和新类型而不会破坏已有客户端。客户端只会返回它们明确请求的字段，忽略其余新字段。字段的废弃也更为简洁，客户端可以收到警告，而无需在整个 API 中引入破坏性更改。

实时能力（订阅）

GraphQL 原生支持订阅（subscriptions），允许客户端订阅事件并实时接收服务器推送的更新。这对聊天应用、实时仪表盘以及其他实时功能极为强大。