什么情况下你会选择 GraphQL 而非 REST，什么情况下不会？

Question

IT Interview Practice · Accepted Answer

根据**谁消费这个 API、以及他们的数据需求有多多样**来选择——而不是跟风。当许多不同的客户端需要各自塑造自己的数据时，GraphQL 胜出；当请求统一、可缓存且简单时，REST 胜出。

## 何时选 GraphQL

- **许多需求各异的客户端** —— web、iOS、Android 都想从同一批实体拿到不同的字段。GraphQL 消除 over/under-fetching，你就不必为每个界面上一个新 endpoint。
- **深度关联/图状数据** —— 一个查询遍历关系（`user -> posts -> comments`），而不是 N 次 REST 往返。
- **快速产品迭代** —— 增量式的 schema 演进让前端团队可以加字段，无需等待新的后端 endpoint 或版本。
- **聚合微服务** —— 一个联邦网关在众多服务之上呈现一张图（BFF 模式）。

## 何时选 REST

- **简单、统一的资源**，且访问可预测——每个客户端都想要相同结构的 CRUD。
- **HTTP 缓存 / CDN 最重要** —— REST 的 URL + `GET` 模型在每一层都能轻松缓存；GraphQL 需要持久化查询才能接近。
- **文件上传/下载、二进制或公开 API**，此时广泛的工具生态、状态码和简单性更占优。
- **小团队 / 低复杂度** —— GraphQL 的服务端成本（resolver、N+1 控制、查询成本限制、schema 工具链）对于寥寥几个 endpoint 不值得。

## 诚实的权衡表

| 关注点 | GraphQL | REST |
|---|---|---|
| Over/under-fetching | 从设计上解决 | 常见问题 |
| HTTP/CDN 缓存 | 难（需额外工作） | 原生且容易 |
| 查询成本/DoS 控制 | 你必须自己加 | 天然有界 |
| 客户端灵活性 | 高 | 低 |
| 服务端复杂度 | 更高 | 更低 |

它们也并非互斥——许多系统为公开/可缓存的 endpoint 暴露 REST，为丰富的内部客户端提供 GraphQL。

## 为什么这很重要

高级面试官考察的是**判断力，而非站队**。强的答案会点明各个维度——客户端多样性、缓存需求、团队成熟度、DoS 攻击面——并承认 GraphQL 真实的成本（缓存与查询成本控制），而不是把它吹成放之四海皆更优。

关注点	GraphQL	REST
Over/under-fetching	从设计上解决	常见问题
HTTP/CDN 缓存	难（需额外工作）	原生且容易
查询成本/DoS 控制	你必须自己加	天然有界
客户端灵活性	高	低
服务端复杂度	更高	更低

何时选 GraphQL

相关问题

何时选 REST

诚实的权衡表

为什么这很重要