什么是 GraphQL
发布: (2026年3月15日 GMT+8 19:20)
4 分钟阅读
原文: Dev.to
Source: Dev.to
概览
- 由 Facebook 开发
- 用于 API 的查询语言
- 因为 API 请求和响应的数据格式相似，使用起来更友好
- REST 是一种架构（设计），而 GraphQL 是一种语言（DSL）
REST 示例
使用 HTTP 动词向多个端点发送请求：
curl https://api.bmf-tech.com/v1/configs[
{
"id": 1,
"name": "title",
"alias_name": "Title",
"value": "bmf-tech",
"created_at": "2017-09-25 23:08:23",
"deleted_at": null
}
]GraphQL 示例
向单一端点发送查询：
curl https://api.bmf-tech.com/api{
configs {
id
name
alias_name
value
created_at
updated_at
deleted_at
}
}[
{
"id": 1,
"name": "title",
"alias_name": "Title",
"value": "bmf-tech",
"created_at": "2017-09-25 23:08:23",
"deleted_at": null
}
]对比摘要
| 功能 | REST | GraphQL |
|---|---|---|
| 端点 | 多个 | 单个 |
| HTTP 动词 | 依赖于端点 | 与端点无关 |
| 类型系统 | 无 | 有 |
| 是否需要版本管理 | 需要 | 不需要 |
| 是否需要文档 | 需要 | 不需要（API 定义本身即为文档） |
| 资源限制 | 主要是调用次数 | 根据资源量自行处理 |
| 响应灵活性 | 每个端点的响应固定 | 客户端指定所需字段 |
| 性能 | 可能需要多次请求 | 请求次数更少，负载更大 |
| 监控 | 可对每个端点进行监控 | 需要自定义查询级别的监控 |
| 缓存 | 可使用 HTTP 缓存 | 不能依赖 HTTP 缓存 |
实际考虑因素
- 负载计算：使用 GraphQL 时通常需要依据返回对象数量等方式进行负载计算。
- 文档：GraphQL 的 schema 本身就是自解释的 API，外部文档的必要性降低。
- 库：实现时通常需要使用解析查询的库。
- 性能：并非天然比 REST 更快，优势在于减少往返次数。
- 数据量：两种方式都需要分页或字段选择来控制负载大小。
- 监控：由于 GraphQL 使用单一端点，可能需要额外工具来跟踪查询级别的性能。
- 缓存：标准的 HTTP 缓存不适用，需要探索其他缓存策略。
何时考虑使用 GraphQL
- 应用拥有众多组件和复杂 UI，导致请求次数成为瓶颈的场景。
- 客户端需要获取多种形状的数据而不想进行多次往返。
资源
- graphql.org – 官方 GraphQL 文档
- facebook/graphql RFCs – 规范与提案
- “A small rebuttal to What is GraphQL suitable for” – 关于使用场景的讨论
- “Memo when implementing GraphQL API in a Rails app” – 实际实现笔记
- “Explaining GraphQL from a beginner’s perspective” – 入门指南，比较 REST 与 GraphQL