Python API开发完整实战用DRF从零搭建一套RESTful接口【免费下载链接】Python-100-DaysPython - 100天从新手到大师项目地址: https://gitcode.com/GitHub_Trending/py/Python-100-Days基于 Python-100-Days 课程本文用一个课程管理系统的真实需求贯穿全程走一遍 Python API 开发的完整动线拆解需求、搭建 DRF RESTful 接口、设计认证、交付文档。读完你能带走一份可直接套用的接口开发模板而不是零散的知识点。需求拆解把课程管理业务翻译成接口任务当产品经理甩来一句前端要展示课程列表还要能增删改查时别急着敲代码先把业务动作翻译成资源操作。REST 风格Representational State Transfer即表现层状态转移要求 URI 指向资源而不是动作——用GET /api/subjects/而不是GET /getSubjects这样接口才见名知意、不随界面改版而失效。业务需求接口任务REST 风格定位浏览课程列表返回列表资源GET /api/subjects/新建课程创建资源POST /api/subjects/修改课程更新资源全量/部分PUT或PATCH /api/subjects/{no}/删除课程移除资源DELETE /api/subjects/{no}/查某课程的老师子资源筛选GET /api/teachers/?sno编号拆解时建议同步确定三件事哪些资源要暴露、每个资源支持哪几个 HTTP 动词、错误时返回什么状态码。这张清单就是后面所有工作的验收标准。骨架搭建DRF 安装与全局配置当你新建好 Django 项目、模型也写完了接下来要让它会说 JSON。直接用原生 Django 视图手搓 JSON 既繁琐又容易漏掉校验而 djangorestframework简称 DRF把序列化、认证、权限、限流全部做成可配置项这是选它而不是裸写视图的理由。安装只需一条命令pip install djangorestframework注册应用并做全局配置。这里每个键都不是随意填的SessionAuthentication服务于 Django 自带后台和浏览器调试页面TokenAuthentication服务于移动端与跨域前端两者并存才能覆盖全部调用方默认权限设为IsAuthenticated等于给自己上保险避免某个新接口裸奔上线。INSTALLED_APPS [ # ... rest_framework, ] REST_FRAMEWORK { PAGE_SIZE: 10, DEFAULT_AUTHENTICATION_CLASSES: [ rest_framework.authentication.SessionAuthentication, rest_framework.authentication.TokenAuthentication, ], DEFAULT_PERMISSION_CLASSES: [ rest_framework.permissions.IsAuthenticated, ], }数据流转序列化与校验当前端问这条课程数据的 JSON 从哪来答案是一条清晰的动线数据库里的模型对象 → 序列化器转成字典 → 视图包成 JSON 响应写操作的动线正好反过来请求体 → 序列化器验证 → 落库。DRF 的序列化器把 Python 对象和 JSON 互相翻译的类是这条动线上的枢纽。如果字段就是模型字段本身继承ModelSerializer是性价比最高的选择它会根据模型自动生成字段定义class SubjectSerializer(serializers.ModelSerializer): class Meta: model Subject fields __all__只有当你需要嵌套资源、只读计算字段或手动拼装结构时才退回更底层的Serializer逐个声明字段——能少写一行是一行。校验则是动线的反向关卡。以学员年龄为例把规则写在validate_字段名方法里非法数据会在入库前被拦下并统一返回 400def validate_age(self, value): if value 18: raise serializers.ValidationError(年龄必须大于等于18岁) return value接口暴露FBV 还是 CBV 的决策当课程列表接口要上线你会在两种写法之间犹豫FBV基于函数的视图直白灵活CBV基于类的视图复用性强。选择标准很简单——逻辑越标准越该用 CBV逻辑越特殊越该用 FBV。场景推荐写法理由一次查询即返回、逻辑简单FBV函数即接口断点调试方便完整 CRUD 四件套ModelViewSet五个 mixin 已实现增删改查几乎零代码只读列表 筛选ListAPIView等泛型视图比全量 ViewSet 少暴露写操作先看 FBV 的最小形态一个装饰器声明允许的动词其余交给序列化器api_view([GET]) def subject_list(request): subjects Subject.objects.order_by(no) serializer SubjectSerializer(subjects, manyTrue) return Response(serializer.data)而课程管理这种标准 CRUDModelViewSet两行声明加一个路由器就完成全部五个接口的注册class SubjectViewSet(ModelViewSet): queryset Subject.objects.all() serializer_class SubjectSerializer # urls.py router DefaultRouter() router.register(api/subjects, SubjectViewSet) urlpatterns router.urlsDRF 还自带可浏览的接口页面没写前端时也能直接发起请求、查看响应联调前的自测全靠它。安全加固Session 与 JWT 的选型当用户登录成功后发出下一次请求无状态的 HTTP 协议让服务器认不出这是谁于是你需要在两种身份跟踪方案里做选择。维度Session 方案JWT 方案身份信息存放位置服务器端 session 对象客户端本地存储请求头携带服务器状态有状态扩容需同步 session无状态加节点即可水平扩展令牌撤销删 session 即刻生效过期前难以作废需短有效期 黑名单典型适用同域 Web 站、Django admin移动端、跨域前后端分离结论是纯浏览器同域应用保留 Session 即可一旦涉及移动端或多节点部署选 JWTJSON Web Token由头部、载荷、签名三段编码拼接的令牌。它的签名机制让伪造和篡改无处遁形而无状态特性天然契合 REST 的水平扩展诉求。代价是令牌泄露风险对策就是缩短有效期敏感操作二次验证。用 PyJWTpip install pyjwt生成与校验各只需几行token jwt.encode( {userid: user.id, exp: datetime.utcnow() timedelta(days1)}, settings.SECRET_KEY, algorithmHS256, ) try: payload jwt.decode(token, settings.SECRET_KEY, algorithms[HS256]) except jwt.PyJWTError: raise AuthenticationFailed(无效的令牌或已过期)交付与协作接口文档规范与测试要点当前端拿到接口却找不到文档时联调就会退化成人肉传话。一份合格的接口文档至少交代清楚请求方法与 URL、每个参数的位置路径/查询/请求头/消息体、成功与失败的状态码约定。以获取文章评论为例GET/api/articles/{article-id}/comments/参数位置必填说明page查询参数否页码默认 1key请求头是用户身份标识{ code: 10000, message: 获取评论成功, page: 1, contents: [ {userId: 1700095, nickname: 王大锤, content: ...} ] }测试别只测正常路径401未认证、404资源不存在、400参数非法这三类异常状态码才是线上事故的高发区。响应体里也建议杜绝裸null从数据库字段设置默认值开始治理前端强类型语言才不会踩坑。踩坑与提速分页、过滤、缓存问答课程列表数据上万前端加载卡顿怎么办全局配置默认分页器让所有列表接口自动带上count、next、resultsREST_FRAMEWORK { DEFAULT_PAGINATION_CLASS: rest_framework.pagination.PageNumberPagination, PAGE_SIZE: 10, }若不想暴露数据总量页码分页会泄露这一点换成CursorPagination游标分页即可。前端要按条件筛选、排序后端要写多少查询代码少量条件直接重写get_queryset从request.GET取值过滤条件多了就上django-filter声明式配置过滤字段class TeacherView(ListAPIView): serializer_class TeacherSerializer filter_backends [DjangoFilterBackend, OrderingFilter] filterset_fields [subject] ordering_fields [no]热门课程接口被反复请求数据库扛不住对读多写少的列表接口套一层缓存15 分钟内的重复请求直接命中class SubjectViewSet(ModelViewSet): method_decorator(cache_page(60 * 15)) def list(self, request, *args, **kwargs): return super().list(request, *args, **kwargs)一套 RESTful 接口从需求到交付本质就是资源定位 → 数据流转 → 身份验证 → 契约交付这四步的循环。接下来可以深入的方向API 版本控制与兼容策略、限流节流防刷、以及用 Celery 把耗时任务从请求线程里剥离出去。【免费下载链接】Python-100-DaysPython - 100天从新手到大师项目地址: https://gitcode.com/GitHub_Trending/py/Python-100-Days创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Python API开发完整实战：用DRF从零搭建一套RESTful接口
Python API开发完整实战用DRF从零搭建一套RESTful接口【免费下载链接】Python-100-DaysPython - 100天从新手到大师项目地址: https://gitcode.com/GitHub_Trending/py/Python-100-Days基于 Python-100-Days 课程本文用一个课程管理系统的真实需求贯穿全程走一遍 Python API 开发的完整动线拆解需求、搭建 DRF RESTful 接口、设计认证、交付文档。读完你能带走一份可直接套用的接口开发模板而不是零散的知识点。需求拆解把课程管理业务翻译成接口任务当产品经理甩来一句前端要展示课程列表还要能增删改查时别急着敲代码先把业务动作翻译成资源操作。REST 风格Representational State Transfer即表现层状态转移要求 URI 指向资源而不是动作——用GET /api/subjects/而不是GET /getSubjects这样接口才见名知意、不随界面改版而失效。业务需求接口任务REST 风格定位浏览课程列表返回列表资源GET /api/subjects/新建课程创建资源POST /api/subjects/修改课程更新资源全量/部分PUT或PATCH /api/subjects/{no}/删除课程移除资源DELETE /api/subjects/{no}/查某课程的老师子资源筛选GET /api/teachers/?sno编号拆解时建议同步确定三件事哪些资源要暴露、每个资源支持哪几个 HTTP 动词、错误时返回什么状态码。这张清单就是后面所有工作的验收标准。骨架搭建DRF 安装与全局配置当你新建好 Django 项目、模型也写完了接下来要让它会说 JSON。直接用原生 Django 视图手搓 JSON 既繁琐又容易漏掉校验而 djangorestframework简称 DRF把序列化、认证、权限、限流全部做成可配置项这是选它而不是裸写视图的理由。安装只需一条命令pip install djangorestframework注册应用并做全局配置。这里每个键都不是随意填的SessionAuthentication服务于 Django 自带后台和浏览器调试页面TokenAuthentication服务于移动端与跨域前端两者并存才能覆盖全部调用方默认权限设为IsAuthenticated等于给自己上保险避免某个新接口裸奔上线。INSTALLED_APPS [ # ... rest_framework, ] REST_FRAMEWORK { PAGE_SIZE: 10, DEFAULT_AUTHENTICATION_CLASSES: [ rest_framework.authentication.SessionAuthentication, rest_framework.authentication.TokenAuthentication, ], DEFAULT_PERMISSION_CLASSES: [ rest_framework.permissions.IsAuthenticated, ], }数据流转序列化与校验当前端问这条课程数据的 JSON 从哪来答案是一条清晰的动线数据库里的模型对象 → 序列化器转成字典 → 视图包成 JSON 响应写操作的动线正好反过来请求体 → 序列化器验证 → 落库。DRF 的序列化器把 Python 对象和 JSON 互相翻译的类是这条动线上的枢纽。如果字段就是模型字段本身继承ModelSerializer是性价比最高的选择它会根据模型自动生成字段定义class SubjectSerializer(serializers.ModelSerializer): class Meta: model Subject fields __all__只有当你需要嵌套资源、只读计算字段或手动拼装结构时才退回更底层的Serializer逐个声明字段——能少写一行是一行。校验则是动线的反向关卡。以学员年龄为例把规则写在validate_字段名方法里非法数据会在入库前被拦下并统一返回 400def validate_age(self, value): if value 18: raise serializers.ValidationError(年龄必须大于等于18岁) return value接口暴露FBV 还是 CBV 的决策当课程列表接口要上线你会在两种写法之间犹豫FBV基于函数的视图直白灵活CBV基于类的视图复用性强。选择标准很简单——逻辑越标准越该用 CBV逻辑越特殊越该用 FBV。场景推荐写法理由一次查询即返回、逻辑简单FBV函数即接口断点调试方便完整 CRUD 四件套ModelViewSet五个 mixin 已实现增删改查几乎零代码只读列表 筛选ListAPIView等泛型视图比全量 ViewSet 少暴露写操作先看 FBV 的最小形态一个装饰器声明允许的动词其余交给序列化器api_view([GET]) def subject_list(request): subjects Subject.objects.order_by(no) serializer SubjectSerializer(subjects, manyTrue) return Response(serializer.data)而课程管理这种标准 CRUDModelViewSet两行声明加一个路由器就完成全部五个接口的注册class SubjectViewSet(ModelViewSet): queryset Subject.objects.all() serializer_class SubjectSerializer # urls.py router DefaultRouter() router.register(api/subjects, SubjectViewSet) urlpatterns router.urlsDRF 还自带可浏览的接口页面没写前端时也能直接发起请求、查看响应联调前的自测全靠它。安全加固Session 与 JWT 的选型当用户登录成功后发出下一次请求无状态的 HTTP 协议让服务器认不出这是谁于是你需要在两种身份跟踪方案里做选择。维度Session 方案JWT 方案身份信息存放位置服务器端 session 对象客户端本地存储请求头携带服务器状态有状态扩容需同步 session无状态加节点即可水平扩展令牌撤销删 session 即刻生效过期前难以作废需短有效期 黑名单典型适用同域 Web 站、Django admin移动端、跨域前后端分离结论是纯浏览器同域应用保留 Session 即可一旦涉及移动端或多节点部署选 JWTJSON Web Token由头部、载荷、签名三段编码拼接的令牌。它的签名机制让伪造和篡改无处遁形而无状态特性天然契合 REST 的水平扩展诉求。代价是令牌泄露风险对策就是缩短有效期敏感操作二次验证。用 PyJWTpip install pyjwt生成与校验各只需几行token jwt.encode( {userid: user.id, exp: datetime.utcnow() timedelta(days1)}, settings.SECRET_KEY, algorithmHS256, ) try: payload jwt.decode(token, settings.SECRET_KEY, algorithms[HS256]) except jwt.PyJWTError: raise AuthenticationFailed(无效的令牌或已过期)交付与协作接口文档规范与测试要点当前端拿到接口却找不到文档时联调就会退化成人肉传话。一份合格的接口文档至少交代清楚请求方法与 URL、每个参数的位置路径/查询/请求头/消息体、成功与失败的状态码约定。以获取文章评论为例GET/api/articles/{article-id}/comments/参数位置必填说明page查询参数否页码默认 1key请求头是用户身份标识{ code: 10000, message: 获取评论成功, page: 1, contents: [ {userId: 1700095, nickname: 王大锤, content: ...} ] }测试别只测正常路径401未认证、404资源不存在、400参数非法这三类异常状态码才是线上事故的高发区。响应体里也建议杜绝裸null从数据库字段设置默认值开始治理前端强类型语言才不会踩坑。踩坑与提速分页、过滤、缓存问答课程列表数据上万前端加载卡顿怎么办全局配置默认分页器让所有列表接口自动带上count、next、resultsREST_FRAMEWORK { DEFAULT_PAGINATION_CLASS: rest_framework.pagination.PageNumberPagination, PAGE_SIZE: 10, }若不想暴露数据总量页码分页会泄露这一点换成CursorPagination游标分页即可。前端要按条件筛选、排序后端要写多少查询代码少量条件直接重写get_queryset从request.GET取值过滤条件多了就上django-filter声明式配置过滤字段class TeacherView(ListAPIView): serializer_class TeacherSerializer filter_backends [DjangoFilterBackend, OrderingFilter] filterset_fields [subject] ordering_fields [no]热门课程接口被反复请求数据库扛不住对读多写少的列表接口套一层缓存15 分钟内的重复请求直接命中class SubjectViewSet(ModelViewSet): method_decorator(cache_page(60 * 15)) def list(self, request, *args, **kwargs): return super().list(request, *args, **kwargs)一套 RESTful 接口从需求到交付本质就是资源定位 → 数据流转 → 身份验证 → 契约交付这四步的循环。接下来可以深入的方向API 版本控制与兼容策略、限流节流防刷、以及用 Celery 把耗时任务从请求线程里剥离出去。【免费下载链接】Python-100-DaysPython - 100天从新手到大师项目地址: https://gitcode.com/GitHub_Trending/py/Python-100-Days创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考