GraphQL 是一种查询语言与运行时：客户端通过单端点发送声明式的查询，按需获取字段与关联数据。REST 基于资源与 HTTP 方法（GET/POST 等），每个资源对应 URL，返回结构相对固定。二者选型会影响前后端协作方式、缓存策略与学习成本。本文介绍 GraphQL 与 REST 的差异、适用场景与选型建议。
一、GraphQL 与 REST 对比
从端点数量、数据获取方式、版本管理、缓存等维度对比，便于选型。
| 维度 | REST | GraphQL |
|---|---|---|
| 端点 | 多端点，按资源（如 /users, /posts） | 单端点（如 /graphql） |
| 数据获取 | 返回固定结构，易多取或少取 | 客户端声明所需字段，按需返回 |
| 版本 | URL 或 Header 版本（如 /v2/users） | Schema 演化，通过废弃字段管理 |
| 缓存 | 可利用 HTTP 缓存（GET 等） | 多为 POST，需自定义缓存策略 |
| 学习成本 | 低，符合 HTTP 语义 | 中高，需理解 Schema、查询与变更 |
| 工具 | Swagger、Postman 等成熟 | GraphiQL、Apollo 等 |
数据来源：GraphQL 与 REST 官方/社区文档（综合整理）。
二、何时适合用 GraphQL
适合场景：① 前端需要灵活组合数据，避免多次请求或过度获取；② 多端（Web、App、第三方）共用一套 API，各取所需；③ 复杂关联与嵌套查询多，用 GraphQL 可读性更好。不适合或需谨慎：简单 CRUD、强依赖 HTTP 缓存、团队对 GraphQL 不熟或无精力维护 Schema。
2.1 N+1 与性能
GraphQL 按字段解析，若每个列表项再查关联数据，易产生 N+1 查询。解决方案：DataLoader 等批处理与缓存层，在解析器层做批量加载。
三、REST 的适用场景
REST 适合资源清晰、CRUD 为主、希望充分利用 HTTP 缓存（GET 幂等、Cache-Control）的项目。与现有网关、监控、安全策略的兼容性通常更好。若 API 需统一鉴权与限流，可参考《API 安全设计最佳实践》。
四、选型要素权重
基于实际项目经验，API 风格选型时以下要素的影响程度（相对权重，满分 100）：
说明：权重基于 API 选型项目实践归纳，仅供参考。
五、小结
GraphQL 适合按需查询与多端复用、关联复杂的场景；REST 适合资源清晰、强依赖 HTTP 缓存的场景。选型需结合业务、团队与运维。若需 Serverless API 设计，可阅读《Serverless 架构实践指南》；若需网关与限流，可参考《API 网关选型与实践》。