尧图网页设计 
RESTful API 设计与实现用 DRF 快速搭建后端接口的完整指南【免费下载链接】Python-100-DaysPython - 100天从新手到大师项目地址: https://gitcode.com/GitHub_Trending/py/Python-100-Days前后端分离的开发里时间消耗最大的环节往往是接口反复返工而问题根源九成出在 URI 设计上。结论先说URI 只负责表示业务实体操作意图全部交给 HTTP 动词表达再把 DRF 的分页、过滤、认证这些机制用起来接口就能做到一次定义、长期稳定。Python-100-Days 仓库里的 Day46-60/54.RESTful架构和DRF入门.md 到 Day46-60/55.RESTful架构和DRF进阶.md 正好覆盖了从架构原则到落地代码的全过程本文按先跑通、再拆原理、最后避坑的路径带你过一遍。接口返工的根源先把资源想清楚URI 该怎么设计直接决定了接口会不会被前端反复吐槽。核心就一条URI 指向资源本身动作交给 HTTP 动词。以订单车间为例请求方法URI 路径表达的动作GET/orders/拉取订单列表POST/orders/新建一笔订单GET/orders/{id}/查询单笔订单PUT/orders/{id}/全量覆盖订单PATCH/orders/{id}/只改订单里的部分字段DELETE/orders/{id}/取消订单动词和 URI 的组合就能无歧义地表达意图服务器无需记住任何客户端信息这就是无状态。无状态不是抠细节而是水平扩展的前提——流量涨了直接加节点不用同步会话数据。最快跑通路径三步接入 DRF要让一个 Django 项目提供 RESTful 接口最少做三件事装包、注册应用、给全局配置。pip install djangorestframework在 settings.py 中把rest_framework加入INSTALLED_APPS并追加全局配置REST_FRAMEWORK { DEFAULT_PAGINATION_CLASS: rest_framework.pagination.PageNumberPagination, PAGE_SIZE: 10, }以书籍资源为例一个序列化器加一个视图类再加一行路由就是最小闭环from rest_framework import serializers from rest_framework.viewsets import ModelViewSet from .models import Book class BookSerializer(serializers.ModelSerializer): class Meta: model Book fields (id, title, author, price, stock) class BookViewSet(ModelViewSet): queryset Book.objects.all() serializer_class BookSerializer路由不用逐条手写交给路由器批量生成from rest_framework.routers import DefaultRouter from .views import BookViewSet router DefaultRouter() router.register(api/books, BookViewSet) urlpatterns router.urls启动后直接访问接口地址DRF 自带一个浏览器调试页能直接发请求、看 JSON前后端联调阶段非常省事。机制拆解DRF 替你省掉的三层代码上一节几乎没写任何处理逻辑原因藏在三层机制里。Serializer进出门都走它序列化器看着是把模型实例变成 JSON 的出口实际上它还是入口POST 请求体先经过 Serializer 校验类型不对、字段缺失、自定义规则不过关一律拒收。类视图五个动作一次配齐类视图CBV把 HTTP 动词的处理逻辑拆成了 MixinModelViewSet一次性混入增、删、改、查五个能力。你只需声明两件事数据从哪来queryset、数据怎么变serializer_class。代价是灵活性不如函数视图——需要复杂业务编排时函数视图里想怎么写就怎么写这是取舍不是缺陷。JWT把登录态搬进客户端传统 session 把登录态存在服务端多节点部署时状态同步很麻烦token 方案恰好相反身份标识交给浏览器本地存储服务端对每次请求只做验签天然无状态。JWT 是这套方案的事实标准由头部、载荷、签名三段编码拼接而成头部声明签名算法与令牌类型载荷存放用户 ID、过期时间等实际数据签名用服务端私钥对前两段做指纹防止伪造import jwt from datetime import datetime, timedelta from django.conf import settings payload {userid: user.id, exp: datetime.utcnow() timedelta(hours2)} token jwt.encode(payload, settings.SECRET_KEY, algorithmHS256).decode() data jwt.decode(token, settings.SECRET_KEY, algorithms[HS256])前端拿到 token 后存入 localStorage每次请求放进请求头服务端验签不通过就统一回 401前端据此跳回登录页。常见坑与优化清单 ⚠️跑通只是起点下面这几件事能决定接口上线后稳不稳。分页别让列表接口裸奔列表接口务必分页。页码分页之外DRF 还内置游标分页CursorPagination客户端只能拿着上一页的游标往后翻无法通过页码反推总数据量对公开接口更友好。单个视图不想跟从全局配置时给它单独指定一个pagination_class即可。过滤与排序把查询逻辑写进 URL按状态、渠道筛选按金额排序这类需求交给django-filter配OrderingFilter一行配置让前端直接用 URL 参数表达复杂查询class BookViewSet(ModelViewSet): filter_backends [DjangoFilterBackend, OrderingFilter] filterset_fields [status, channel] ordering_fields [amount, create_time]缓存只给读操作开门读多写少的列表接口挂上cache_page数据库压力立降但写操作千万别误伤进缓存否则下单之后查到的还是旧数据。JWT 的三件麻烦事令牌一旦泄露就等同交出用户全部权限有效期宁短勿长敏感操作叠加短信二次验证已签发的令牌在过期前无法主动作废需要踢人下线就得引入黑名单存储token 存浏览器天然暴露在 XSS 面前输出转义别偷懒。文档给前端一个稳定的合同响应结构、状态码含义、参数位置在文档里定死再开发。仓库里的 Day91-100/94.网络API接口设计.md 有一份可直接套用的接口文档模板错误码规划、参数表、示例响应一应俱全。收束RESTful 的骨架是URI 表资源、动词表动作DRF 的价值在于把序列化、校验、分页、路由这些重复劳动收敛成配置。想继续往前走的三个方向接口版本控制策略、限流与熔断、Celery 异步任务处理——对应的延伸阅读都收在 Python-100-Days 仓库的 Day46-60 与 Day91-100 目录里。【免费下载链接】Python-100-DaysPython - 100天从新手到大师项目地址: https://gitcode.com/GitHub_Trending/py/Python-100-Days创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RESTful API 设计与实现：用 DRF 快速搭建后端接口的完整指南
RESTful API 设计与实现用 DRF 快速搭建后端接口的完整指南【免费下载链接】Python-100-DaysPython - 100天从新手到大师项目地址: https://gitcode.com/GitHub_Trending/py/Python-100-Days前后端分离的开发里时间消耗最大的环节往往是接口反复返工而问题根源九成出在 URI 设计上。结论先说URI 只负责表示业务实体操作意图全部交给 HTTP 动词表达再把 DRF 的分页、过滤、认证这些机制用起来接口就能做到一次定义、长期稳定。Python-100-Days 仓库里的 Day46-60/54.RESTful架构和DRF入门.md 到 Day46-60/55.RESTful架构和DRF进阶.md 正好覆盖了从架构原则到落地代码的全过程本文按先跑通、再拆原理、最后避坑的路径带你过一遍。接口返工的根源先把资源想清楚URI 该怎么设计直接决定了接口会不会被前端反复吐槽。核心就一条URI 指向资源本身动作交给 HTTP 动词。以订单车间为例请求方法URI 路径表达的动作GET/orders/拉取订单列表POST/orders/新建一笔订单GET/orders/{id}/查询单笔订单PUT/orders/{id}/全量覆盖订单PATCH/orders/{id}/只改订单里的部分字段DELETE/orders/{id}/取消订单动词和 URI 的组合就能无歧义地表达意图服务器无需记住任何客户端信息这就是无状态。无状态不是抠细节而是水平扩展的前提——流量涨了直接加节点不用同步会话数据。最快跑通路径三步接入 DRF要让一个 Django 项目提供 RESTful 接口最少做三件事装包、注册应用、给全局配置。pip install djangorestframework在 settings.py 中把rest_framework加入INSTALLED_APPS并追加全局配置REST_FRAMEWORK { DEFAULT_PAGINATION_CLASS: rest_framework.pagination.PageNumberPagination, PAGE_SIZE: 10, }以书籍资源为例一个序列化器加一个视图类再加一行路由就是最小闭环from rest_framework import serializers from rest_framework.viewsets import ModelViewSet from .models import Book class BookSerializer(serializers.ModelSerializer): class Meta: model Book fields (id, title, author, price, stock) class BookViewSet(ModelViewSet): queryset Book.objects.all() serializer_class BookSerializer路由不用逐条手写交给路由器批量生成from rest_framework.routers import DefaultRouter from .views import BookViewSet router DefaultRouter() router.register(api/books, BookViewSet) urlpatterns router.urls启动后直接访问接口地址DRF 自带一个浏览器调试页能直接发请求、看 JSON前后端联调阶段非常省事。机制拆解DRF 替你省掉的三层代码上一节几乎没写任何处理逻辑原因藏在三层机制里。Serializer进出门都走它序列化器看着是把模型实例变成 JSON 的出口实际上它还是入口POST 请求体先经过 Serializer 校验类型不对、字段缺失、自定义规则不过关一律拒收。类视图五个动作一次配齐类视图CBV把 HTTP 动词的处理逻辑拆成了 MixinModelViewSet一次性混入增、删、改、查五个能力。你只需声明两件事数据从哪来queryset、数据怎么变serializer_class。代价是灵活性不如函数视图——需要复杂业务编排时函数视图里想怎么写就怎么写这是取舍不是缺陷。JWT把登录态搬进客户端传统 session 把登录态存在服务端多节点部署时状态同步很麻烦token 方案恰好相反身份标识交给浏览器本地存储服务端对每次请求只做验签天然无状态。JWT 是这套方案的事实标准由头部、载荷、签名三段编码拼接而成头部声明签名算法与令牌类型载荷存放用户 ID、过期时间等实际数据签名用服务端私钥对前两段做指纹防止伪造import jwt from datetime import datetime, timedelta from django.conf import settings payload {userid: user.id, exp: datetime.utcnow() timedelta(hours2)} token jwt.encode(payload, settings.SECRET_KEY, algorithmHS256).decode() data jwt.decode(token, settings.SECRET_KEY, algorithms[HS256])前端拿到 token 后存入 localStorage每次请求放进请求头服务端验签不通过就统一回 401前端据此跳回登录页。常见坑与优化清单 ⚠️跑通只是起点下面这几件事能决定接口上线后稳不稳。分页别让列表接口裸奔列表接口务必分页。页码分页之外DRF 还内置游标分页CursorPagination客户端只能拿着上一页的游标往后翻无法通过页码反推总数据量对公开接口更友好。单个视图不想跟从全局配置时给它单独指定一个pagination_class即可。过滤与排序把查询逻辑写进 URL按状态、渠道筛选按金额排序这类需求交给django-filter配OrderingFilter一行配置让前端直接用 URL 参数表达复杂查询class BookViewSet(ModelViewSet): filter_backends [DjangoFilterBackend, OrderingFilter] filterset_fields [status, channel] ordering_fields [amount, create_time]缓存只给读操作开门读多写少的列表接口挂上cache_page数据库压力立降但写操作千万别误伤进缓存否则下单之后查到的还是旧数据。JWT 的三件麻烦事令牌一旦泄露就等同交出用户全部权限有效期宁短勿长敏感操作叠加短信二次验证已签发的令牌在过期前无法主动作废需要踢人下线就得引入黑名单存储token 存浏览器天然暴露在 XSS 面前输出转义别偷懒。文档给前端一个稳定的合同响应结构、状态码含义、参数位置在文档里定死再开发。仓库里的 Day91-100/94.网络API接口设计.md 有一份可直接套用的接口文档模板错误码规划、参数表、示例响应一应俱全。收束RESTful 的骨架是URI 表资源、动词表动作DRF 的价值在于把序列化、校验、分页、路由这些重复劳动收敛成配置。想继续往前走的三个方向接口版本控制策略、限流与熔断、Celery 异步任务处理——对应的延伸阅读都收在 Python-100-Days 仓库的 Day46-60 与 Day91-100 目录里。【免费下载链接】Python-100-DaysPython - 100天从新手到大师项目地址: https://gitcode.com/GitHub_Trending/py/Python-100-Days创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考