介绍

到 2024 年，GraphQL 和 REST 之间的争论已显着成熟。这两种方法都在不断发展，互相采用了彼此的功能，并找到了各自的定位。问题不再是哪个普遍优越，而是哪个适合您的特定项目环境。本文提供了平衡的比较，以帮助团队做出明智的 API 架构决策。

2024 年的休息状态

REST 仍然是占主导地位的 API 范例，为大多数 Web API 提供支持。它的优势在于成熟、简单和通用 HTTP 缓存。 OpenAPI 3.1 规范带来了 JSON Schema 兼容性，提高了互操作性。 Swagger UI、Redoc 和 Postman 集合等工具提供了出色的文档和测试功能。

REST 的缓存优势非常显着。 HTTP 缓存适用于每一层（CDN、浏览器和反向代理），使用 ETag、Last-Modified 和 Cache-Control 等标准标头。这使得 REST 对于具有可缓存响应的读取密集型工作负载特别有效。

然而，REST 的局限性仍然存在。 过度获取（接收超过需要的数据）和获取不足（需要多个请求来收集相关数据）是固有问题，特别是对于移动应用程序和复杂的 UI。 GitHub REST API v3 迁移到 GraphQL v4 就体现了这个痛点。

2024 年 GraphQL 的状况

GraphQL 已经成熟为生产就绪的生态系统。 Apollo 客户端和服务器、Relay、urql 和 Yoga 提供了强大的实现。 GraphQL 代码生成器提供类型安全的代码生成，许多团队发现它优于基于 OpenAPI 的生成。

性能改进解决了早期的批评。 DataLoader 通过批处理和缓存消除了 N+1 查询问题。 持久查询和自动持久查询 (APQ) 可减少请求开销。 GraphQL 的 CDN 级缓存现在可以通过持久化查询 ID 和 CDN 配置实现。

GraphQL 联邦（Apollo Federation、HyperGraphQL）的兴起使得 GraphQL 对于微服务架构来说变得可行。网关模式允许团队从多个服务组合架构，同时向客户端提供统一的 API。

性能深度探究

网络负载分析显示，REST 通常在简单的资源获取方面胜出，而 GraphQL 则擅长满足复杂的嵌套数据需求。在一个视图中需要用户配置文件、最近订单和通知的仪表板 UI 可能需要 3-5 个 REST 请求，但只需要 1 个 GraphQL 请求。

工具和开发人员经验

GraphQL 的强类型模式通过内省提供内置 API 文档，支持使用 GraphQL 和 Apollo Studio Explorer 等工具进行交互式查询开发。 REST 依赖 OpenAPI/Swagger UI 来实现类似的功能，这需要显式维护。

决策框架

在 REST 和 GraphQL 之间进行选择时，请考虑以下因素：

迁移模式

对于考虑迁移的团队，建议采用渐进的方法。使用 Apollo REST 数据源通过 GraphQL 网关包装 REST 端点可以实现增量采用：

class UsersAPI extends RESTDataSource {
  constructor() {
    super();
    this.baseURL = 'https://api.example.com/';
  }

  async getUser(id) {
    return this.get(`users/${id}`);
  }
}

这种方法允许团队采用 GraphQL 每个功能，同时维护现有的 REST 端点，从而降低迁移风险。

结论

2024 年 GraphQL 和 REST 之间的选择取决于项目特定的约束而不是趋势。 GraphQL 提供了灵活性和类型安全性，但代价是缓存的复杂性。 REST 提供简单性和通用缓存，但代价是潜在的过度获取和不足获取。构建简单 CRUD 应用程序的小团队应该偏爱 REST。具有复杂 UI 和嵌套数据需求的应用程序可以从 GraphQL 中受益。微服务环境应考虑 GraphQL 联合。关键是根据您的实际需求进行评估，而不是跟随行业炒作。