Appearance
GraphQL 与 REST：围绕查询形态和治理成本选型
修订于 2026-10-12。没有一种 API 风格在所有场景中都更快；性能结论应基于具体实现与负载。
REST 通常以资源和 HTTP 语义组织接口；GraphQL 通过类型系统和查询语言让客户端选择所需字段。它们都能构建稳定 API，差别主要在查询灵活度和治理方式。
| 问题 | REST 常见做法 | GraphQL 常见做法 |
|---|---|---|
| 获取关联数据 | 多个资源请求，或提供专门聚合接口 | 一次查询请求多个关联字段 |
| 版本演进 | 管理端点与表示的兼容性 | 以字段弃用和 schema 演进为主 |
| 缓存 | HTTP 语义通常更直接 | 常需结合操作、变量和业务策略设计 |
| 成本控制 | 按端点设置上限 | 还需限制查询深度、复杂度与批量 |
| 授权 | 在资源/操作层校验 | 每个可访问字段仍需考虑授权 |
GraphQL 能减少某些多次往返，但嵌套字段可能带来 N+1 查询或昂贵的解析。官方安全指南建议对操作复杂度、深度、分页和速率做约束。REST 也可能因端点设计不当产生过多往返。两者都需要真实调用链与负载测试。
选型步骤
- 列出客户端的真实数据需求和变更频率。
- 明确缓存、授权、审计、错误处理与分页要求。
- 用代表性查询实现原型，比较端到端延迟、后端负载和维护成本。
- 设计 schema 或资源模型的兼容变更机制。
GraphQL over HTTP 对部分成功响应有具体状态码建议，因此监控不能只把“HTTP 2xx”视为业务成功；还应检查响应中的错误与数据。采用哪种方案都应写清客户端可预期的失败契约。