AI 摘要：本文指出传统手动编写 REST API 的方式存在重复、易错和效率低等问题，建议开发者在 2025 年采用基于 schema 的声明式 (declarative) API 架构。文章通过对比 Express + yup 的旧式流程与 tRPC + Zod 等现代框架的 schema 驱动方案，展示了后者在类型安全、自动文档生成和开发效率上的明显优势。文末总结，这一趋势代表了 API 开发范式的转变：不再从零搭建 REST，而是借助框架实现「单一事实源 (Single Source of Truth)」的自动化、类型安全和可维护性。

1. 传统 REST API 的问题
• 以 Express + yup 为例，展示编写一个 POST /users 接口的流程需要多次定义相同结构（TypeScript 接口与验证 schema），违反 DRY 原则。
• 手动设置中间件、类型转换、错误捕获、更新文档等步骤繁琐且易出错。
• 代码重复导致类型不同步、文档过时等潜在风险。

2. 基于 schema 的声明式解决方案
• 引入 tRPC + Zod：仅需定义一次 schema，即可自动推导类型、内建验证、生成文档。
• 省去中间件与显式类型转换，错误由框架统一处理。
• 实现「一份定义，三方同步」：类型、安全与文档共用同一 schema。

3. 行业框架的趋势与示例
• Hono：以标准 Web API 语法结合 zValidator 内置验证，简化 Express 式编写。
• Fastify：通过 schema 改进性能，将类型安全转化为运行时效率，并生成 JSON Schema。
• NestJS：通过装饰器 (decorator) 方式实现 declarative 验证与类型推断，无需手动配置。

4. 对比与优势总结
• 开发速度：传统方案冗长且易同步出错，schema 驱动模式定义一次即可。
• 安全性与可靠性：旧式依靠手动转换，schema 模式实现端到端类型安全。
• 文档维护：旧方式需手写 OpenAPI，schema 模式可自动生成实时文档。

5. 结论与未来趋势
• 手工编写 REST API 已成为反模式，schema 驱动的 declarative 模型是未来标准。
• 关键价值在于「写更好的代码」，而非「写更少的代码」。
• 单一 schema 即为验证层、类型系统与文档源，使开发更快、更安全、更可维护。

LogRocket Blog

Stop writing REST APIs from scratch in 2025 - LogRocket Blog

Writing REST APIs by hand is a thing of the past. Frameworks like tRPC, Fastify, and Hono eliminate boilerplate with schema-driven design, improving speed and safety.