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):data=json.loads(request.body)errors={}ifnotdata.get("name"):errors["name"]=["该字段不能为空。"]try:age=int(data.get("age"))except(TypeError,ValueError):errors["age"]=["请输入整数。"]iferrors:returnJsonResponse(errors,status=400)returnJsonResponse({"name":data["name"],"age":age},status=201)

这段代码仍然能工作，但邮箱格式、字符串长度、取值范围、嵌套对象、批量写入和统一错误格式都需要自己补齐。

REST 框架把校验变成声明

同样的输入规则，用序列化器可以写成：

fromrest_frameworkimportserializersclassProfileSerializer(serializers.Serializer):name=serializers.CharField(max_length=20)age=serializers.IntegerField(min_value=0,max_value=120)email=serializers.EmailField(required=False)

处理请求时调用：

serializer=ProfileSerializer(data=request.data)serializer.is_valid(raise_exception=True)data=serializer.validated_data

字段声明同时承担类型转换、边界检查和错误组织。后续换成ModelSerializer，还可以与模型创建、更新和字段约束连接起来。

六组输入验证

实验环境：Python 3.12.1、Django 6.1 RC1、Django REST framework 3.16.1。测试规则为：姓名必填且最多 20 个字符，年龄必须是 0 到 120 的整数，邮箱可选但格式必须有效。

仅看这六组结果，两种方案都能写对。真正的区别是维护成本：手写方案需要开发者主动覆盖每个分支；序列化器把规则集中在字段定义里，并自动生成结构化错误。

微基准结果应该怎么理解

我又对同一条正确输入执行 7 轮测试，每轮 5000 次：

这个结果只能说明：在不包含 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 框架分页