REST 与 GraphQL

REST 和 GraphQL 是从服务器获取数据的两种架构。REST 使用多个端点；GraphQL 使用一种查询语言。这篇笔记涵盖权衡和什么时候每一个都有意义。在现代 Web 开发中，选择合适的数据获取策略对应用性能和开发效率都有重大影响。REST 的成熟生态系统和简单性使其在许多场景下仍是首选，而 GraphQL 的灵活性在复杂前端需求中展现出独特价值。理解两者的设计哲学和适用场景，能够帮助开发团队做出更明智的技术决策。本笔记通过对比分析和实际案例，深入探讨这两种架构的核心差异。

基本想法

在 REST 中，获取整个资源（用户、帖子）及其所有字段。如果需要相关数据（用户的帖子或帖子的评论），需要获取单独的资源。这会导致 N+1 问题和浪费过度获取。GraphQL 让您声明在一个查询中跨相关资源要的确切字段。服务器仅返回您要求的内容。

权衡是复杂性。REST 易于实现和缓存。GraphQL 需要查询解析和验证，缓存更复杂。对于带宽有限的移动客户端，GraphQL 通常更好。对于简单的、服务器驱动的 API，REST 通常更简单。

数学

设 n 为需要获取的相关资源数。

REST：需要 n 个 HTTP 请求，每个资源一个。总传输字节数包括每个响应中的未使用字段。
GraphQL：需要 1 个 HTTP 请求。总传输字节数仅是请求的内容。

当 n 很大且每个资源有许多未使用字段时，延迟节省最大。如果 n=1 且需要所有字段，REST 和 GraphQL 等效。

动手试

小工具展示 REST 响应（多个请求，瀑布流）和 GraphQL 响应（单一查询）。检查所需字段并查看差异。更大的选择使 GraphQL 的优势更清晰。这个交互式演示模拟了真实的网络请求场景，包括每次请求的延迟和数据传输大小。通过直观地比较两种方法，可以清楚地看到 GraphQL 在减少网络往返次数方面的优势。同时，也能观察到当只需要少量字段时，REST 的简单性可能更适合。建议尝试不同的字段组合，观察性能差异如何随选择复杂度变化。

REST (waterfall)

GET /api/users/1

→ round trip 1

GET /api/users/1/posts

→ round trip 2 (waits for the first)

GraphQL (single)

POST /graphql

→ 1 round trip (nested fields resolved on the server)

3 fields selected

REST 和 GraphQL 获取用户数据的比较。检查字段以查看延迟和数据大小差异。

REST 需要多个往返；GraphQL 只需要一个。
检查更多字段使 REST 中过度获取更明显。
缓存头工作方式不同：REST 是基于头；GraphQL 需要应用级缓存。

我在哪用到它

容易出错的地方

参考资料

GraphQL 官方graphql.org
RESTful API 设计restfulapi.net

在各个项目中比较（2022-2026）。这些实践经验帮助我深入理解了两种架构的适用场景。REST 的成熟工具链和广泛支持使其成为快速原型开发的首选，而 GraphQL 在需要精细控制数据传输的场景中展现出明显优势。在实际项目中，技术选择往往需要权衡多个因素：团队经验、现有基础设施、性能需求、开发效率以及长期维护成本。通过对比不同项目的实施经验，可以更清晰地认识到没有绝对的优劣，只有更适合具体场景的方案。