RESTful & FastAPI 面试速查笔记

slug

type

Post

status

Published

date

May 10, 2026

1. 什么是 API？(底层心智模型)

API = 一份契约（Contract）

两个核心特征：

功能性：你给我 A，我给你 B

稳定性：契约不变，两边可独立演化（这是软件能扩展的根本机制）

关键术语：解耦（Decoupling）。契约的本质是降低耦合，让模块之间「井水不犯河水」。

面试金句："API 不只是接口，更是一份让两端独立演化的承诺面。"

2. RESTful 三件套

部分	作用	例子
URL	资源的"地址"（名词）	`/users/123`
Method	对它做什么（动词）	`GET / POST / PUT / PATCH / DELETE`
Body	资源的"内容"（键值对）	`{"name": "Felix"}`

核心原则：URL 全是名词，动作藏在 method 里。

反模式：POST /getUserById、POST /deleteUser ❌

3. 集合路径 vs 单体路径

ㅤ	`/users`（集合）	`/users/123`（单体）
GET	查所有用户	查 ID=123
POST	创建新用户 ✓	一般不用
PUT	一般不用	全量替换 ✓
PATCH	一般不用	部分修改 ✓
DELETE	危险，禁用	删 ID=123 ✓

记忆口诀：集合配 POST/GET，单体配 GET/PUT/PATCH/DELETE。

4. PUT vs PATCH

PUT：全量替换（body 必须包含完整资源）

PATCH：部分修改（body 只含要改的字段）

HTTP 没有 UPDATE 方法（容易和 SQL 的 UPDATE 混淆）

实践中 PATCH 用得更多。

5. 状态码（必背）

2xx 成功：200 OK / 201 Created / 204 No Content

4xx 客户端错：400 参数错 / 401 没登录 / 403 没权限 / 404 找不到

5xx 服务端错：500 内部错误 / 503 服务不可用

反模式：所有错误返回 200，靠 body 里的 code 字段区分 ❌

6. 幂等性（高频考点）

精确定义：

多次执行后，服务器的状态是否一致——而不是返回的状态码是否一致。

Method	幂等？	理由
GET	✅	只读
DELETE	✅	删完后状态恒定为「不存在」（陷阱：第二次返回 404 不影响幂等性！）
POST	❌	每次创建新资源
PUT	✅	全量替换，结果恒定
PATCH	视情况	`{age: 26}` 幂等；`age + 1` 不幂等

陷阱题：DELETE 第二次返回 404 是否破坏幂等性？

答：不破坏。幂等性看服务器状态，不看响应。

7. POST 如何"工程化"实现幂等？(高分加分点)

问题：下单这种 POST 接口必须支持重试（网络抖动），但 POST 天生不幂等。

方案：Idempotency-Key

客户端在请求前生成唯一字符串（UUID），放在 Header

服务器维护「key → 处理结果」映射，重复 key 直接返回上次结果

key 的过期时间通常 24 小时（Stripe 标准）

POST /orders
Header: Idempotency-Key: abc-123-uuid
Body: {商品信息}

面试金句："Stripe、支付宝这类支付系统都用 Idempotency-Key 处理金融级 POST 重试。"

8. 无状态（Stateless）

RESTful 的灵魂：每个请求自带全部信息，服务器不"记忆"上次发生了什么。

好处：

服务器可以横向扩展（任何一台都能处理）

重启不丢上下文

抵抗故障

9. 登录 / 认证

纯 RESTful 做法：把 token 看作资源

登出 = DELETE /sessions，header 带 Authorization

实用做法（业界更常见）：POST /auth/login / POST /auth/logout

面试加分答法：

"纯 RESTful 我会用 POST /sessions 把 token 资源化。但实际项目里 /auth/login 也常见，因为对前端开发者更直观——这是 RESTful 理想 vs 工程实用的经典 tradeoff。"

10. JWT vs Session

ㅤ	Session	JWT
信息存哪	服务器（小本本）	客户端自带
服务器有状态？	有	无
验证方式	拿 ID 查数据库	验签名
横向扩展	难（要共享 session 存储）	易

JWT 三段结构：头部.信息.签名

前两段公开（base64 编码，可解开看）

第三段 = HMAC(前两段 + 服务器密钥)

关键洞察：

密钥永远不在网络上传输，只待在服务器机房

服务器不存 token，每次重新算签名验证

服务器重启/换机器后旧 token 仍可用——只要密钥相同

面试金句："JWT 用密码学保证无状态认证。服务器不需要记忆，只需要会重新执行验证算法。"

11. HTTPS 一句话

"HTTPS 在 TCP 上加了一层 TLS 加密，让传输内容（包括 token）不会被中间人窃听或篡改。token 本身不加密没关系，HTTPS 这一层保护了它在网络上的传输。"

12. FastAPI 核心概念

python

from fastapi import FastAPI

app = FastAPI()

@app.get("/users/{user_id}")
def get_user(user_id: int):
    return {"id": user_id, "name": "Felix"}

FastAPI 帮你做的事：

@app.get(...) → 把 Python 函数贴上「URL 名片」，变成 HTTP 接口

user_id: int → 自动类型转换 + 校验（不通过返回 422）

return {...} → 自动序列化 Python 字典 → JSON 文本

框架的灵魂：让开发者只写业务逻辑，不写进出请求的脏活。

13. 序列化（Serialization）

核心命题：进程之间互相隔离（操作系统级别的「井水不犯河水」），跨进程传输只能走文本/字节。

链路：

Python字典  →[序列化]→  JSON文本  →HTTP→  JSON文本  →[反序列化]→  JS对象
   (活的)                (死的)               (死的)                (活的)

类比：Python 字典 = 做好的菜（离开厨房就坏）；JSON = 菜谱（任何大厨都能照做）。

为什么是 JSON：

跨语言通用

人类可读

结构简单（只有 string/number/bool/null/array/object 几种类型）

名字源自 JavaScript Object Notation，但已成为独立标准

14. 几个面试常见问题的标准答案

Q：RESTful 的设计原则？

A：六大原则——客户端-服务器分离、无状态、可缓存、统一接口、分层系统、按需代码。重点讲无状态和统一接口。

Q：PUT 和 POST 的区别？

A：PUT 幂等（全量替换某个具体资源），POST 不幂等（创建新资源，每次会产生不同 ID）。本质区别在 URL 颗粒度和幂等性。

Q：怎么保证 POST 接口幂等？

A：客户端生成 Idempotency-Key 放 Header，服务器维护「key → 结果」映射，重复 key 返回上次结果，过期时间 24 小时。

Q：JWT 为什么是无状态的？

A：token 自带身份信息（前两段），签名保证未被篡改（第三段）。服务器只用密钥重新算签名验证，不需要存 token。

Q：什么是好的 API 设计？

A：URL 是名词、method 是动词、状态码用对、幂等性正确、版本可控、错误信息清晰。背后哲学是「契约稳定 + 解耦」。

给你的临场口诀

遇到 RESTful 题，先问三个问题：

这是资源还是动作？（动作要资源化）

这是集合还是单体？（决定能用哪些 method）

这个操作幂等吗？（决定能不能重试）