【API 风格入门】REST、GraphQL、tRPC 到底怎么选？

INFO

本文介绍我对当前API风格的学习与梳理

一、为什么我开始关注「接口风格」？

最近在深入学习全栈开发，准备往更系统、更专业的方向走。过程中，我发现一个绕不开的话题，就是API 接口风格。

无论是前端和后端怎么联动、多人协作时怎么分工、还是未来要不要支持 App、小程序，这背后其实都指向一个核心问题：

接口怎么设计，才高效、可扩展、好维护？

于是，我开始认真整理和学习市面上主流的 API 风格：

• REST ➡️ 经典工业标准
• GraphQL ➡️ 灵活声明式查询
• tRPC ➡️ 新一代全栈 TypeScript 接口方案

这篇文章，就是我这段学习过程中的个人笔记，帮自己也帮你，理一理它们之间的异同和适用场景。

二、REST：老牌接口风格，今天依然主流

✅ 它的特点：

• 按照「资源」来设计接口，比如 /api/users/:id、/api/videos/:id
• 使用 HTTP 方法来区分操作：GET（查）、POST（增）、PUT（改）、DELETE（删）
• 各大公司、框架、第三方服务都普遍采用

🌱 适合入门场景：

• 学习 API 设计基础
• 前端和后端分仓开发
• 跨端（Web、App、小程序）统一接口

❌ 但也有痛点：

• 接口数量容易膨胀（复杂页面往往要多个接口组合）
• 数据获取容易「多拿少拿」不够精准
• 前后端联调迭代成本偏高

📝 我的学习体会：REST 是打基础必学的，它帮我掌握了 API 设计的基本原则和习惯。但当我想提升「接口联动效率」的时候，开始意识到它的局限。

三、GraphQL：接口数量不再膨胀，数据按需获取

GraphQL 是那种你早晚得了解、早晚会敬佩的技术。它不是简单的「REST 替代品」，而是一套彻底重构前后端接口协作思维的方案。

一句话总结 GraphQL：

客户端说了算，接口返回啥、怎么拼，都由前端精确控制。

这种范式，直接打破了传统 REST API 的「一个接口，一份数据，一刀切」规则，让前端开发者真正拥有了接口主动权。

我的理解：GraphQL 本质上是声明式数据获取

和 REST API（动词 + 路径）不同，GraphQL 是声明式的：

query {
  user(id: "123") {
    id
    name
    avatar
    posts {
      id
      title
    }
  }
}

这里前端直接告诉后端：「我需要这个用户的 id、name、avatar，顺便再把 posts 带回来，但只要 id 和 title」——后端就得照办，按需返回。

这个体验，说实话，对我做前端这么久的感受就是两个字：爽感。 因为再也不用为了一个「多一点点字段」去找后端「加接口、改接口、扩接口」。

为什么 GraphQL 会让接口设计「质变」？

我总结了几点，让我真正意识到 GraphQL 带来的变革：

• 📝 前端自由拼装数据：一个查询搞定，以前 REST 里得调 3~4 个接口，现在一条 GraphQL Query 全部拿下。
• 🚀 Overfetch/Underfetch 问题直接消灭：不会多返回、不少返回，返回什么，前端定义。
• ♻️ 强类型 API：GraphQL 天然带类型系统，前端调用时有 IDE 补全和类型提示，和 TypeScript 简直天生一对。
• 🔄 实时数据（Subscription）：除了 Query 和 Mutation，GraphQL 还能原生支持 WebSocket 实时推送，轻松搞定聊天、通知、在线状态这种场景。

对我们这种想做「现代化产品」的开发者来说，这些特性，个个都直击痛点。

当然，GraphQL 也有它的「坑」

我也冷静观察了一下，GraphQL 不是银弹，它也踩过一些实际团队的坑：

• 💥 服务端实现复杂：要搞 Resolvers、Schema Stitching，维护成本不低，特别是在数据源复杂时；
• 🚥 权限控制细粒度：你得设计字段级、查询级的权限规则，否则容易被「任意查询」拖垮；
• 🧱 缓存策略不同于 REST：因为 Query 是动态的，传统 HTTP 缓存、CDN 缓存机制用不上，得靠 Apollo/Relay 这种客户端缓存方案来补；
• 🏋️‍♂️ 适合中大型项目：对于小项目，GraphQL 的学习成本和基础设施开销相对偏高。

所以我的体会是：

GraphQL 很强，但它适合「规模稍大、团队协作多、数据结构复杂」的场景，小而简单的项目，用 REST 或 tRPC 其实更轻便。

我眼中的 GraphQL 和 tRPC 的关系

很多人会问：「学了 tRPC 还要学 GraphQL 吗？」

我自己的感受是：

• tRPC 属于 TypeScript 圈内的全栈接口方案，前端和后端都是 TS，类型自动同步，非常丝滑，适合 Monorepo、小团队、TS-only 场景。
• GraphQL 是 跨语言、跨端、跨团队 都能统一的一套标准化协议，适合前端、App、后端、甚至外部合作方都调用同一套接口的场景。

简单说：

• 做个人项目、小型前后端分离？tRPC 很爽。
• 想做大型产品、多端接入、复杂数据关系？GraphQL 才是「职业级工具」。

所以对我自己来说，我会两者都掌握，因为它们分别适配不同层次的实战场景。

接下来的学习路线，我打算这么走

我也帮自己梳理了一下下一步学习 GraphQL 的路径，分享给你，咱们可以一起走：

1. 理解 Schema、Query、Mutation、Subscription 这套基本概念；
2. 学会用 Apollo Server 或 Yoga 快速搭建后端 API；
3. 前端用 Apollo Client 或 urql，体验「按需取数」和「客户端缓存」；
4. 练习几个实战场景：
   • 用户信息查询（带嵌套字段）
   • 登录注册（Mutation）
   • 聊天室实时消息（Subscription）
5. 最后，挑战一个小型「全栈 GraphQL 项目」，比如任务管理器、博客系统。

等到这套走通了，再来考虑：GraphQL 怎么和我的大项目（比如 Atom Video）融合，或者以后大型 B 端项目怎么规划接口架构。

四、tRPC：TypeScript 全栈开发者的「丝滑接口体验」

tRPC 真的很像前端工程师量身定制的全栈接口方案。它不像传统 API 那样接口和类型「漂」来「漂」去，也不用学一堆复杂的 Schema 和代码生成。简单来说，它的体验就一句话：

用 TypeScript，一边写接口，一边自动同步类型，前端直接像调用函数一样调 API。

这个设计，说实话，第一次接触时我有点震撼。因为它直接打通了我们前端和后端之间那层「类型墙」，尤其适合像我这种想往全栈进阶，但又不想陷入重复劳动的前端开发者。

我的理解：tRPC 本质上是「类型驱动的 RPC」

和传统 REST API、GraphQL 不同，tRPC 做的是过程式调用。也就是说，后端暴露出来的是函数，前端直接调这个函数，TypeScript 自动帮你补全参数和返回值的类型，安全感直接拉满。

比如，传统 REST 接口是这样调的：

const res = await fetch('/api/user?id=123');
const user = await res.json();

但是用 tRPC，直接这样：

const user = await trpc.user.getById.query({ id: '123' });

这里的 user 的类型，是从后端代码里自动同步过来的，完全不会漂，也不需要我手动对齐类型。这体验，真的很像在写本地函数，不像是在调远程 API。

为什么它适合前端人学？我自己的感受

我认真体验下来，觉得 tRPC 很适合作为前端工程师的全栈进阶跳板，因为：

• 类型自动同步，不需要再写重复的 Request/Response 类型了；
• 不依赖代码生成，不像 GraphQL/OpenAPI 那样需要 build SDK；
• React 生态集成得好，可以直接和 React Query 联动，缓存、loading、error 状态管理一条龙；
• 前后端协作变简单，尤其适合 Monorepo、团队小、节奏快的项目。

这不就是我们前端开发者理想中的 API 体验吗？一边写接口，一边 VSCode 自动补全，哪里错类型直接红线提示，连联调的心智负担都减轻了。

当然，tRPC 也不是万能的

我也看到它的局限，尤其是在我做 Atom Video 这种想往多端扩展的项目时，tRPC 可能就没那么「通用」了。

因为：

• tRPC 只能跑在 TypeScript 技术栈里，像 App、小程序、Flutter 这种跨语言客户端，目前没法直接用；
• 前后端最好在同一个仓库（Monorepo），如果是大厂那种前端、后端分仓开发，就不太适合；
• 一些高级场景（SEO、权限控制、缓存策略）还需要我们自己设计，tRPC 本身是「轻框架」，不会帮你兜底。

所以我的结论是：

tRPC 非常适合小团队、初创项目、个人开发，或者全栈 TypeScript 场景，但要做跨端、跨语言、分仓大项目，还是 REST/GraphQL 更保险。

下一步，我准备怎么学 tRPC？

虽然现在我还没在 Atom Video 这种生产项目里用 tRPC，但我已经打算先用它来练练手。比如：

• 搭一个简单的评论系统或任务管理器；
• 用 Next.js App Router + tRPC 来体验一下全栈开发的完整链路；
• 顺便研究一下和 React Query 的联动，感受一下 tRPC 的缓存和状态管理能力。

我的目标也很明确：

先掌握 tRPC 这套「类型同步 + 全栈调用」的新范式，为我后面做更现代化、系统化的产品打好基础。

总结一下我的感悟：

• tRPC 不是银弹，但它真的让前端人也能舒服地玩转全栈。
• 它帮我们省掉了接口类型漂移、重复劳动、联调心智负担，让 API 调用体验变得「前端友好」。
• 它适合小而美的项目，但要走大规模、跨端路线，还得搭配其他方案。

这次学 tRPC，也让我对未来团队协作和 API 模块化设计有了新的理解。我会继续深入，也期待把这套新技能，未来应用到我自己的产品里，真正体验一次类型驱动开发的爽感

五、结语：接口风格，决定了你的开发节奏

学 API 风格，不只是为了写接口本身，它其实关乎：

• 团队协作怎么分工
• 前后端怎么联动高效
• 项目未来怎么扩展

这次学习，让我对接口设计有了新的理解，也对自己未来做更系统的全栈开发，更有信心了 💪

未来计划

后续将在实践中深入掌握各个API风格