FastAPI保姆级入门：前后端分离与API设计核心概念

FastAPI 作为目前 Web 框架领域速度极快的技术，正受到越来越多后端开发者的关注。B站UP主老肖的这套保姆级教程，从 Web 开发模式讲起，逐步深入 FastAPI 本身与 SQLAlchemy 2.0 的整合。本文基于该教程的核心内容，梳理 FastAPI 入门必须掌握的几组概念。

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

在 Web 开发中，前后端不分离是一种较老的开发模式。浏览器看到的界面效果、界面中展示的数据，以及按钮点击后弹出的特效，全部由同一个应用服务器提供。服务器内部既要写业务逻辑代码，又要写数据处理代码，还要写界面渲染代码。

这种模式的痛点在于：界面设计必须先完成，否则后端无法将数据嵌入页面进行渲染，开发效率因此大打折扣。而且前后端代码耦合在一起，无法按技术拆分团队。对于 FastAPI 学习者来说，这种模式只需了解即可，重点应放在前后端分离上。

前后端分离：按技术拆分，各司其职

前后端分离将界面与数据彻底拆开。前端服务器专门存放 HTML、CSS、JS 以及图片等静态文件，因此常被称为静态文件服务器；Python 应用服务器则专注处理业务逻辑并返回数据。两者独立开发、独立部署，只要需求确认，前后端团队就能并行推进。这也是目前企业级 Web 项目最流行的开发模式，绝大多数项目都采用这种架构。

在分离模式下，浏览器请求界面时访问前端服务器，请求数据时访问 Python 应用服务器。后端返回的数据格式以 JSON 为主，因为它简洁、跨语言且操作方便，无论是浏览器、手机 App 还是微信小程序，都能统一消费同一套 API 返回的 JSON 数据。后端只负责处理逻辑和提供数据，数据最终展示在哪里，由客户端自行决定。

JSON（JavaScript Object Notation） 是一种轻量级的文本数据交换格式，源于 JavaScript 的对象字面量语法，但已成为语言无关的标准（RFC 8259）。它仅支持对象、数组、字符串、数字、布尔值和 null 六种数据类型，结构简洁、可读性强，几乎所有编程语言都内置或可通过库快速解析与生成 JSON。相比 XML，JSON 体积更小、解析更快，因此在 Web API 领域取代 XML 成为事实上的主流数据格式。在前后端分离架构中，后端将业务数据序列化为 JSON 返回，前端或客户端反序列化后渲染展示，从而实现界面与数据的解耦。

FastAPI 的定位：为 API 而生的后端框架

FastAPI 底层基于 Starlette，而 Starlette 从一开始就是为 API 接口开发设计的。因此 FastAPI 天生适合前后端分离项目，主打后端开发。不过它也能通过整合 Jinja2 模板引擎实现界面渲染，从而支持前后端不分离的场景，只是官方文档的重点仍然偏向 API 后端开发。

理解前后端分离，是理解 FastAPI 设计哲学的前提。FastAPI 的目标就是对外提供统一的 API 接口，让任意客户端都能按需获取数据。

Starlette 是一个轻量级的 ASGI（Asynchronous Server Gateway Interface）框架/工具包，为 Python 异步 Web 开发提供路由、中间件、请求/响应对象、WebSocket、后台任务等基础能力。ASGI 是继 WSGI 之后的新一代 Python Web 服务器网关接口标准，支持异步协程与长连接。FastAPI 并不重复实现这些底层机制，而是构建在 Starlette 之上，专注提供基于类型注解的参数校验、依赖注入和自动生成 OpenAPI 文档等能力，因此其性能与异步特性很大程度上继承自 Starlette。

Jinja2 是 Python 生态中最常用的模板引擎，采用类似 Django 模板的语法，通过 {{ 变量 }}、{% 控制语句 %} 等占位符将动态数据嵌入 HTML 模板并渲染成最终页面。FastAPI 可通过 Jinja2Templates 集成 Jinja2，在返回 HTML 响应的同时保留 API 开发能力，这正是它能够兼顾前后端不分离场景的原因。

API 接口与 REST 规范

API（Application Programming Interface）是应用程序对外提供的数据操作入口，可以是一个函数、一个类，也可以是一个 URL 地址。目前主流的 API 接口规范有 REST 和 RPC 两种。RPC 是一种接口开发协议，而 REST 更常被称为开发风格，本质上是人为约定的通信规则。当前市场上 REST 占据主流，原因在于它使用方便且安全性较高。

REST 全称为 Representational State Transfer，直译成中文反而难以理解，只需把它当作一个规范名称即可，就像 ISO9001 是质量管理体系的名称一样。REST 是一种面向资源的编程模式，把所有 API 接口都视为资源，资源即数据。定义接口时，客户端访问的 URL 路径就代表要操作的数据资源。

RPC（Remote Procedure Call，远程过程调用） 是一种让客户端像调用本地函数一样调用远程服务器上函数的协议风格，强调“动作”而非“资源”，常见实现包括 gRPC、JSON-RPC、XML-RPC 等。RPC 接口通常以动词命名（如 getUser、createOrder），并可通过 IDL（接口定义语言）严格约定参数与返回结构，适合内部服务间高性能通信。REST 与 RPC 的核心区别在于抽象视角：REST 以资源为中心，用 URL 标识资源、用 HTTP 方法表达操作；RPC 以过程为中心，用方法名表达行为。二者各有适用场景，REST 更贴近 HTTP 语义、通用性更强，因而在对外开放 API 中更为流行。

用请求方法表达操作语义

在 REST 风格下，对同一资源的不同操作通过请求方法来区分：

• 添加学生：使用 POST 请求，路径指向学生集合
• 获取所有学生：使用 GET 请求，路径指向学生集合
• 获取某个学生：使用 GET 请求，路径后接学生 ID
• 修改学生：使用 PUT 或 PATCH 请求，路径后接学生 ID
• 删除学生：使用 DELETE 请求，路径后接学生 ID

同一资源路径搭配不同请求方法，就构成了语义清晰的接口体系。这也是 FastAPI 路由设计中会反复用到的核心思路。掌握前后端分离与 REST 资源建模这两组概念，再进入 FastAPI 的接口开发、参数校验与异步处理，学习路径会顺畅很多。

PUT 与 PATCH 都用于修改资源，但语义不同：PUT 表示用请求体完整替换目标资源，客户端需提交资源的全部字段，未提交的字段通常被置空或恢复默认值；PATCH 表示对资源进行部分更新，只需提交要修改的字段，未提及的字段保持不变。REST 还强调幂等性：GET、PUT、DELETE 是幂等的，多次执行与执行一次的效果相同；POST 通常非幂等，重复提交可能创建多条记录。理解这些语义有助于设计出行为可预期、易于缓存和重试的接口。