REST APIVSGraphQL
REST API vs GraphQL
拥有 20 多年历史的 REST 对决源自 Facebook 的 GraphQL。为移动应用后端选择 API 设计范式时，该如何取舍？
tRPC vs REST 对比
面向 TypeScript 的端到端类型安全 API
VS
REST
自 2000 年以来的语言无关行业标准
9 分钟阅读Backend
评分对比
图表加载中…
详细评分
| 分类 | tRPC | REST |
|---|---|---|
| 性能 | 9/10 | 9/10 |
| 学习难易度 | 8/10 | 10/10 |
| 生态系统 | 8/10 | 10/10 |
| 社区 | 9/10 | 10/10 |
| 就业市场 | 7/10 | 10/10 |
| 面向未来 | 8/10 | 8/10 |
优缺点
tRPC
优点
- 从服务端到客户端的类型安全——无需代码生成
- 内联 Zod 校验
- 原生集成 React Query
- 支持订阅（WebSocket）
- 中间件与上下文系统
- 无需维护 OpenAPI/GraphQL schema
- Theo 的 t3-stack 的核心支柱
- 被 Vercel、Cal.com、Cloudflare 等采用
缺点
- 仅支持 TypeScript——多语言团队使用困难
- 移动端/原生客户端与 TS 不兼容（需要 REST/GraphQL）
- 不适合作为公开 API（没有开放规范）
- 大型单体仓库会增加构建时间
最适合
TypeScript 全栈应用（Next.js、Remix）内部 API（服务端与网页客户端由同一团队维护）对类型安全要求严格的场景需要快速迭代的场景（schema 变更立即反映到客户端）类似 T3 stack 的工程实践项目
REST
优点
- 语言无关——可对接任意客户端
- 25 年以上的行业标准积淀
- OpenAPI/Swagger 生态系统成熟
- 原生支持 HTTP 缓存（Cloudflare、Varnish）
- 公开 API 的标准方案
- 移动端/原生客户端可直接对接
- 工具链通用（Postman、curl）
- 长期向后兼容
缺点
- 类型安全需手动实现（需要 OpenAPI 代码生成）
- 样板代码繁重——路由、校验器、类型需要分别维护
- 存在过度获取/获取不足的问题（这正是 GraphQL 诞生的原因）
- 版本管理较为复杂（v1、v2、废弃处理）
最适合
公开 API多语言团队（iOS、Android、Web、第三方）需要长期稳定的 API高缓存需求场景（Cloudflare 边缘节点）需要符合行业标准规范
代码对比
tRPC
// server/router.ts
export const appRouter = t.router({
getUser: t.procedure
.input(z.object({ id: z.string() }))
.query(async ({ input }) => {
return await db.user.findUnique({ where: { id: input.id } });
}),
});
// client (type-safe, autocomplete!)
const user = await trpc.getUser.query({ id: "123" });
// user.name, user.email — fully typedREST
// OpenAPI-first
GET /api/users/:id
Response: { "id": "123", "name": "Ali", "email": "..." }
// Client (manual type def veya codegen)
const res = await fetch("/api/users/123");
const user: User = await res.json(); // Manual type assertion结论
TypeScript 全栈单体仓库（monorepo）→ 选择 tRPC（类型安全的黄金标准）。公开 API 且客户端语言多样 → 选择 REST。GraphQL 是折中方案——类型安全且语言无关，但复杂度较高。混合方案：内部使用 tRPC，对外提供 REST 门面。
获取免费咨询常见问题
常见问题
GraphQL 属于另一种设计范式——查询语言。tRPC 与 REST 之争是 TypeScript 与通用方案之争，GraphQL 可以作为混合策略的一部分。