17370845950

Python接口系统的核心是理解请求-响应机制、数据序列化、状态管理与错误处理四大底层逻辑；第54讲聚焦HTTP语义合规性，强调GET/POST不可互换、201优于200标识创建、JSON需设Content-Type、错误需具体化、序列化须契约化、状态须明确归属、实战需兼顾校验/事务/响应设计。

Python接口系统的核心在于理解请求-响应机制、数据序列化、状态管理与错误处理这四个底层逻辑，而不是堆砌框架语法。第54讲的重点不是教你怎么写一个Flask路由，而是帮你看清：为什么GET和POST在接口语义上不可互换？为什么JSON响应里加个Content-Type: application/json比返回纯字符串重要得多？为什么状态码201比200更适合新建资源？

HTTP协议本质是接口的骨架

所有Python接口框架（Flask、FastAPI、Django REST）都只是对HTTP标准的封装。不理解方法语义、状态码含义、头字段作用，就容易写出“能跑但不合规”的接口。

• GET必须是安全且幂等的——不能用于删数据或改状态；用GET传敏感参数（如token）会暴露在URL和日志中
• POST用于创建资源，但真正标识“成功创建”的是201状态码 + Location响应头指向新地址，而非只返回{"success": true}
• 400类错误要带具体原因（如{"error": "email format invalid"}），而不是笼统返回400；500不该把traceback发给前端

数据序列化不是“转成JSON”那么简单

从Python对象到HTTP响应体，中间涉及编码、验证、脱敏、嵌套控制多个环节。FastAPI的Pydantic模型、Flask的marshmallow，本质都是在定义“可被网络传输的数据契约”。

• 日期字段默认转成字符串，但前端可能需要时间戳；需统一约定格式（如ISO 8601）并在文档中标明
• 数据库模型直接jsonify(model.__dict__)很危险——可能泄露密码字段、内部ID、未初始化属性
• 嵌套层级过深（如用户→订单→商品→分类→品牌）会导致响应体积大、解析慢；应按场景提供精简视图（DTO）

状态管理要分清“谁的状态”

接口本身无状态，但业务离不开状态。关键是要明确状态存在哪、生命周期多长、谁负责清理。

• 用户登录态：用JWT时，payload里别塞太多数据；密钥轮换、过期刷新、黑名单退出都要设计到位
• 临时上传凭证：生成带签名的预签名URL（如AWS S3），有效期精确到分钟，服务端不存凭证记录
• 长任务进度：不要用session存进度，改用Redis哈希结构存task_id→{status, progress, result}，前端轮询或接WebSocket

实战案例：一个合规的“提交订单”接口该怎么写

不是展示代码行数，而是聚焦三个决策点：

• 输入校验：用Pydantic定义OrderCreate模型，约束address长度、product_ids为非空列表、quantity为正整数；自动拒绝非法字段（如传了"admin": true）
• 事务边界：库存扣减和订单写入必须在同一个数据库事务内；失败时回滚并返回409 Conflict + {"error": "inventory insufficient"}
• 响应设计：成功返回201，Body含order_id、created_at、payment_url；同时设置Cache-Control: no-store防止CDN缓存敏感数据

不复杂但容易忽略。