FastAPI 入门第一课：读懂前后端分离与 RESTful API

从 Web 开发模式说起

在正式接触 FastAPI 之前，理解它诞生的技术背景很关键。B站UP主老肖在这套 FastAPI 教程的开篇没有急于写代码，而是先把 Web 开发的两种基础模式讲清楚——因为 FastAPI 的设计定位，恰恰是由这两种模式的差异决定的。

所谓 Web 开发，绕不开一个核心问题：浏览器最终看到的界面、特效和数据，究竟由谁来提供？围绕这个问题，业界演化出了「前后端不分离」和「前后端分离」两种截然不同的思路。搞懂它们的区别，才能明白为什么 FastAPI 会成为当下后端开发的热门选择。

前后端不分离：一个服务器包办一切

前后端不分离是几年前较为传统的开发模式。它的特征很直接：浏览器看到的所有内容——界面本身、界面上的按钮特效、以及展示的数据——全部由同一个服务器提供。

这个过程可以拆解为：浏览器发出请求，应用服务器接收后到数据库查询数据，对数据做处理，再套上业务逻辑，最后把数据和界面一起渲染成一个完整的 HTML 页面返回给浏览器。也就是说，业务逻辑代码、数据处理代码和界面渲染代码，全都要写在同一个服务器里。

这种模式有两个明显痛点。一是开发效率低——因为界面和数据耦合在一起，设计界面必须先出来，后端才能把数据填进页面渲染；二是无法按技术做拆分，前后端团队难以并行工作。因此，老肖在教程中建议这部分「以了解为主」，真正的重点在后者。

前后端分离：企业级项目的主流选择

前后端分离的核心思路是按技术做拆分。前端的 HTML、CSS、JS 这三类内容放到一个专门的服务器（也称静态文件服务器）中开发和部署；后端的业务逻辑代码、数据处理代码则放到一个 Python 应用服务器中运行。

这样做最大的区别是：至少有两个服务器，一个专门处理前端，一个专门处理后端。带来的直接好处是团队可以并行开发——只要需求确认，前端团队和后端团队就能同时启动，不必再等界面做完后端才动工。据老肖介绍，这也是目前企业级 Web 项目最流行的模式，占比在 90% 以上。

在这种架构下，浏览器的请求是分散的：想要界面就请求前端服务器，想要数据就请求 Python 应用服务器。而后端服务器对外提供统一的 API 接口，无论请求来自浏览器、微信小程序还是安卓/iOS 手机 App，它只负责处理业务逻辑、返回数据，至于客户端拿数据去哪展示，则完全不管。

值得一提的是数据格式。当前后端返回的数据 95% 以上都采用 JSON 格式——它简洁、跨语言、操作方便。而早期常见的 XML 已属于较老的技术，如今大多被 JSON 取代。

FastAPI 的定位：天生为分离架构而生

理解了两种模式，就能明白 FastAPI 的定位。老肖强调，FastAPI「一生来就是为前后端分离这种开发模式提供的」。

它的底层基于 Starlette，而 Starlette 本身从一开始就是专门做 API 接口、做后端开发的框架。这决定了 FastAPI 的主战场是前后端分离的后端服务开发。

那么它能不能做前后端不分离的项目？答案是可以。由于基于 Starlette，FastAPI 也能整合 Jinja2 模板引擎，实现界面渲染（前后端不分离才需要界面渲染）。但这并非它的主要用途——它更偏向以后端开发为主，被定位为「未来最主流、运行速度最快的对外服务后端框架」。

Starlette 是一个轻量级的 Python 异步 Web 框架/工具包，由 Tom Christie 开发，构建于 ASGI（Asynchronous Server Gateway Interface，异步服务器网关接口）标准之上。与传统的 WSGI 框架（如 Django、Flask）不同，ASGI 原生支持异步操作，使得框架可以在处理一个请求的 I/O 等待期间（如数据库查询、网络请求）切换去处理其他请求，从而大幅提升并发性能。FastAPI 直接继承了 Starlette 的全部特性，包括 WebSocket 支持、后台任务、中间件机制等，并在其基础上增加了数据验证（基于 Pydantic）、自动生成交互式 API 文档（Swagger UI 和 ReDoc）等能力。这也是为什么 FastAPI 在性能基准测试中能与 Node.js 和 Go 比肩的根本原因——它的高性能不是靠优化技巧堆砌出来的，而是异步架构在底层决定的。

什么是 API 接口与 RESTful 规范

API 全称 Application Programming Interface，即应用程序编程接口。它是应用程序对外提供的一个操作数据的入口——这个入口可以是一个函数、一个类，也可以是一个 URL 网络地址。客户端只要向这个入口发送请求，就能调用它。

目前主流的 API 接口规范有两种：REST 和 RPC。RPC 是一种接口开发协议；REST 则常被称为「开发风格」，本质上也是人为约定的一套开发规则。两者都是规范，只是 RPC 目前市场占有率不高，主流仍是 REST——因为它足够方便，安全性也较高。

REST 全称 Representational State Transfer，直译为「具象状态转移」。老肖提醒，这个中文翻译不必深究——它就像 ISO9001 一样，只是一个国际通行规范的名字而已。

REST 的核心是面向资源的编程模式。它把所有 API 接口都看成一个资源，客户端请求某个接口就能获得对应的资源，而资源本质上就是数据。在这种理念下，后端的任务就是对外提供数据资源的访问接口，定义接口时用 URL 路径来表示要操作的资源。

对同一个资源，通过不同的请求方法来表达不同操作。以「学生」这个资源为例：

• POST /students：添加一个学生
• GET /students：获取所有学生
• GET /students/1：获取 ID 为 1 的学生
• PUT /students/1：修改 ID 为 1 的学生
• DELETE /students/1：删除 ID 为 1 的学生

可以看到，请求路径和请求方法的组合，清晰地表达了「对哪个资源做什么操作」。这种以资源为中心、用统一动词表达操作的思路，正是 RESTful API 的精髓，也是 FastAPI 开发中反复用到的基础。

RPC（Remote Procedure Call，远程过程调用） 与 REST 的根本区别在于设计理念：REST 以「资源」为中心，用 URL 描述名词（操作的对象），用 HTTP 方法描述动词（做什么）；而 RPC 则以「动作」为中心，接口直接描述一个可调用的函数，例如 getUserById(1) 或 deleteStudent(1)。常见的 RPC 实现包括 Google 推出的 gRPC（基于 Protocol Buffers 和 HTTP/2）以及 JSON-RPC 等。gRPC 在微服务内部通信场景中颇为流行，因为它传输效率更高、接口契约更严格；但对于面向浏览器或移动端的公开 API，REST 因其更好的可读性、与 HTTP 语义的天然契合以及广泛的工具链支持，仍然是压倒性的首选。FastAPI 的设计完全围绕 REST 理念展开，路由装饰器 @app.get()、@app.post() 等本身就是对 HTTP 方法语义的直接映射。

小结

这堂开篇课虽然没有写一行 FastAPI 代码，却铺垫了理解这个框架的关键地基：前后端分离决定了 FastAPI 的后端定位，JSON 是它的默认交流语言，而 RESTful 规范则是它组织接口的方法论。掌握这些概念后，再去学习路由、依赖注入、Pydantic、异步和 ORM 等具体特性，就会更加水到渠成。