DRF凭什么更高效？Django原生API与DRF框架开发对比解析

一、原生 Django 开发 API 的局限性

虽然 Django 可以通过 JsonResponse 和视图函数手动构建 API，但存在以下问题：

1. 手动序列化与反序列化
   需要手动将模型实例转换为 JSON，处理复杂数据类型（如嵌套关系）时代码冗长且易错。

示例：原生 Django 返回 JSON 数据

from django.http import JsonResponse
from .models import Book

def book_list(request):
    books = Book.objects.all()
    data = [{"title": book.title, "author": book.author} for book in books]
    return JsonResponse(data, safe=False)
缺点：无法自动处理模型关联、验证输入数据，且代码重复率高。

2. 复杂的请求处理
   需要手动解析请求体中的 JSON 数据，并处理不同 HTTP 方法（GET/POST/PUT/DELETE）。

示例：原生处理 POST 请求

import json
from django.views.decorators.csrf import csrf_exempt

@csrf_exempt
def create_book(request):
    if request.method == "POST":
        try:
            data = json.loads(request.body)
            book = Book.objects.create(**data)
            return JsonResponse({"id": book.id}, status=201)
        except Exception as e:
            return JsonResponse({"error": str(e)}, status=400)

缺点：缺少自动数据验证、错误处理逻辑复杂。

3. 缺乏标准化功能
   需自行实现以下功能：

    认证与权限（如 Token、JWT、OAuth）。
    
    分页（处理大数据集的分页逻辑）。
    
    限流（防止 API 被滥用）。
    
    文档生成（手动维护 API 文档）。
   

4. 维护成本高
   随着项目规模扩大，手动编写的 API 代码难以统一管理，容易产生冗余和潜在安全漏洞。

二 、DRF 的核心优势

DRF 针对上述问题提供了系统化解决方案，显著提升开发效率与代码质量。

1. 序列化与反序列化自动化
   序列化器（Serializer）：

自动将模型实例转换为 JSON，支持复杂关系（如一对多、多对多）。

内置数据验证逻辑，确保输入数据符合预期格式。

示例：DRF 序列化器

from rest_framework import serializers
class BookSerializer(serializers.ModelSerializer):
    class Meta:
        model = Book
        fields = "__all__"

2. 视图抽象化
   视图集（ViewSets） 和 通用视图（Generic Views）：

通过 ModelViewSet 自动生成 CRUD 接口，减少 70% 的重复代码。

示例：DRF 视图

from rest_framework import viewsets
class BookViewSet(viewsets.ModelViewSet):
    queryset = Book.objects.all()
    serializer_class = BookSerializer

3. 开箱即用的高级功能

功能	原生 Django 实现难度	DRF 实现方式
认证	高（需手动集成）	一行配置（authentication_classes）
权限控制	高	一行配置（permission_classes）
分页	中	内置分页类（PageNumberPagination）
限流	高	配置 throttle_classes
API 文档	高（需第三方库）	自动生成（swagger、redoc）

4. 标准化与安全性
   认证方案：支持 Token、Session、JWT、OAuth2 等。

   权限粒度：基于角色（IsAdminUser）、对象级别（DjangoObjectPermissions）的权限控制。

   安全防护：自动处理 CSRF、XSS 等常见安全问题。

5. 生态系统与社区支持
   扩展插件：支持 django-filter（过滤）、drf-yasg（文档）、djangorestframework-simplejwt（JWT 认证）等。

活跃社区：GitHub 15k+ Stars，Stack Overflow 上超 10 万相关问题，解决问题更高效。

三、典型场景对比

场景：开发一个支持过滤、分页和权限控制的图书 API
原生 Django：

# 需要手动实现过滤、分页、权限逻辑，代码量约 100+ 行
from django.core.paginator import Paginator
def book_list(request):
    # 过滤
    author = request.GET.get("author")
    books = Book.objects.filter(author=author) if author else Book.objects.all()
    # 分页
    paginator = Paginator(books, 10)
    page = paginator.get_page(request.GET.get("page"))
    # 手动序列化
    data = [{"title": book.title} for book in page]
    return JsonResponse({"results": data, "count": paginator.count})

DRF：

#通过配置实现相同功能，代码量 10 行
from rest_framework import viewsets, filters
class BookViewSet(viewsets.ModelViewSet):
    queryset = Book.objects.all()
    serializer_class = BookSerializer
    filter_backends = [filters.SearchFilter]
    search_fields = ["author"]
    pagination_class = PageNumberPagination
    permission_classes = [IsAuthenticated]

四、何时选择原生 Django？

尽管 DRF 优势明显，但在以下场景可能更适合原生 Django：

1.极简 API：仅需返回少量简单数据。

2.性能敏感：DRF 的抽象层可能带来轻微性能开销（通常可忽略）。

3.避免依赖：项目要求最小化第三方库。

五、总结

维度	原生 Django	DRF
开发效率	低（需手动实现所有功能）	高（开箱即用，代码量减少 50%+）
功能完整性	基础	完整（认证、权限、分页、限流等）
维护成本	高（代码冗余，难扩展）	低（标准化配置，易于迭代）
安全性	需自行处理	内置防护机制
适用场景	简单接口或小型项目	中大型项目、需标准化 API 的企业应用

结论：DRF 是 Django 生态中构建 API 的“工业级”工具，其设计哲学与 Django 一致（DRY原则），适合绝大多数需要高效、安全、可维护的 API 开发场景。原生 Django 仅适用于极简需求或对性能/依赖有严格限制的特殊情况。