Django 接口开发实测：新手还需要使用 REST 框架吗？

Django 接口开发实测新手还需要使用 REST 框架吗Django 自带JsonResponse接收请求、查询数据库、返回 JSON 都能完成。于是很多新手会问既然原生 Django 已经可以写接口为什么还要安装 REST 框架这个问题不能只看“能不能返回 JSON”。我用同一组输入分别实现了手写校验和 Django REST framework 序列化器对比它们在正确输入、缺少字段、类型错误、范围错误和扩展能力上的差异。结论先说小型只读接口可以先用原生 Django只要开始处理写入、权限、分页和统一错误REST 框架通常更省事。原生 Django 写接口并不难一个最小接口可能只有几行fromdjango.httpimportJsonResponsedefprofile(request):returnJsonResponse({name:大鹏,age:36})如果它只读取固定数据没有复杂参数、认证和分页这种写法清晰、依赖少也容易调试。问题从接收外部输入时开始出现importjsonfromdjango.httpimportJsonResponsedefcreate_profile(request):datajson.loads(request.body)errors{}ifnotdata.get(name):errors[name][该字段不能为空。]try:ageint(data.get(age))except(TypeError,ValueError):errors[age][请输入整数。]iferrors:returnJsonResponse(errors,status400)returnJsonResponse({name:data[name],age:age},status201)这段代码仍然能工作但邮箱格式、字符串长度、取值范围、嵌套对象、批量写入和统一错误格式都需要自己补齐。REST 框架把校验变成声明同样的输入规则用序列化器可以写成fromrest_frameworkimportserializersclassProfileSerializer(serializers.Serializer):nameserializers.CharField(max_length20)ageserializers.IntegerField(min_value0,max_value120)emailserializers.EmailField(requiredFalse)处理请求时调用serializerProfileSerializer(datarequest.data)serializer.is_valid(raise_exceptionTrue)dataserializer.validated_data字段声明同时承担类型转换、边界检查和错误组织。后续换成ModelSerializer还可以与模型创建、更新和字段约束连接起来。六组输入验证实验环境Python 3.12.1、Django 6.1 RC1、Django REST framework 3.16.1。测试规则为姓名必填且最多 20 个字符年龄必须是 0 到 120 的整数邮箱可选但格式必须有效。输入场景手写校验序列化器正确姓名、年龄、邮箱通过通过缺少姓名拒绝拒绝年龄为abc拒绝拒绝年龄为 130拒绝拒绝姓名超过 20 个字符拒绝拒绝带一个未知字段通过通过并忽略未声明字段仅看这六组结果两种方案都能写对。真正的区别是维护成本手写方案需要开发者主动覆盖每个分支序列化器把规则集中在字段定义里并自动生成结构化错误。微基准结果应该怎么理解我又对同一条正确输入执行 7 轮测试每轮 5000 次方案单次校验中位数手写校验函数0.29 微秒REST 序列化器44.15 微秒这个结果只能说明在不包含 HTTP、数据库和业务逻辑的隔离校验中功能更多的序列化器开销更大。它不能推出“手写接口比 REST 框架快 152 倍”更不能代表生产吞吐。真实接口的耗时通常还包括网络、认证、数据库查询、序列化、日志和缓存。是否使用框架应根据复杂度和维护成本决定而不是拿一个微基准替代完整压测。哪些场景可以不用 REST 框架下面这些情况原生 Django 往往足够只有一两个内部只读接口返回结构固定没有复杂输入权限直接复用现有登录会话不需要统一分页、限流和版本管理团队明确愿意维护自己的错误格式。例如健康检查、简单统计数字和后台页面的一次性异步请求用JsonResponse更直接。哪些场景建议尽早使用1. 接口开始写数据一旦出现创建、更新和批量操作输入校验会迅速膨胀。序列化器能统一字段校验、对象级校验和错误响应。2. 需要认证与权限REST 框架把认证和权限拆成独立策略。身份认证只负责识别调用者权限类再决定能否访问两者不是一回事。对移动端、前后端分离或第三方调用来说这个边界很重要。3. 列表需要分页数据少时直接返回数组没有问题数据增长后就需要页码、下一页地址、总数和统一格式。REST 框架的通用视图和视图集可以自动接入分页普通APIView仍需要显式调用分页器。4. 团队需要一致的接口结构解析器、渲染器、异常处理、限流和版本策略统一后新接口不会每个人写出一种风格。框架带来的收益主要是工程一致性而不是“返回 JSON”这一个功能。新手最容易犯的三个错误错误一一上来就堆 ViewSet如果还不理解请求方法、状态码、序列化和权限直接复制完整视图集很容易只会套模板。更好的顺序是先写一个原生JsonResponse接口再用序列化器重构观察框架具体替你完成了什么。错误二把认证等同于权限知道“你是谁”不代表允许“你删除这条数据”。REST 框架会先运行认证再执行权限和限流检查业务接口仍要选择正确的权限策略。错误三为了性能删掉所有校验隔离微基准里手写函数更快不代表生产系统应该省略类型、长度、权限和异常处理。性能优化应该从真实请求链路和数据库查询开始。我的最终结论新手不需要为了输出一段 JSON 立即安装 REST 框架但应该在第一个包含写入、权限或分页的真实接口出现时认真评估它。可以记住这条分界线原生 Django 解决“这个接口能不能工作”REST 框架更擅长解决“一批接口能不能长期保持一致”。先理解原生请求与响应再学习序列化器、认证、权限和分页比只会复制脚手架更有价值。参考资料Django 请求与响应文档REST 框架序列化器REST 框架认证REST 框架分页