⚖️ Старый vs Новый: DRF-блок

🎯 Устаревшие паттерны → Django 5.x / DRF 3.15+ К оглавлению урока

⚡ Главные устаревшие паттерны

  1. Отдельные маршруты для каждого метода → объединённые маршруты REST.
  2. JsonResponse напрямую → Response из DRF.
  3. FBV без @api_view → APIView или Generic views.
  4. request.GET вместо request.query_params.
  5. Ручной JSON-парсинг request.body → request.data.

1. Отдельные маршруты для каждого CRUD-метода

Из лекции (старое)

# urls.py — отдельные маршруты
urlpatterns = [
    path('books/', book_list),
    path('books/create/', book_create),
    path('books/<pk>/', book_detail),
    path('books/<pk>/update/', book_update),
    path('books/<pk>/delete/', book_delete),
]

Современный подход (REST)

# urls.py — объединённые REST-маршруты
urlpatterns = [
    path('books/', book_list_create),
    path('books/<int:pk>/', book_detail_update_delete),
]
# GET/POST /books/
# GET/PUT/PATCH/DELETE /books/{pk}/

Единый REST-ресурс соответствует принципам HTTP: коллекция и один объект — два URL.

2. JsonResponse вместо Response из DRF

Из лекции (старое)

from django.http import JsonResponse

@api_view(['GET'])
def hello_world(request):
    return JsonResponse({'message': 'Hello, World!'})

Современный подход

from rest_framework.response import Response

@api_view(['GET'])
def hello_world(request):
    return Response({'message': 'Hello, World!'})

Response из DRF поддерживает content negotiation (JSON, Browsable API, XML и др.), корректно обрабатывает коды статусов и рендереры.

3. FBV без @api_view → APIView / Generic

Из лекции (старое)

from django.http import JsonResponse

def my_view(request):
    if request.method == 'GET':
        return JsonResponse({'data': 'ok'})
    elif request.method == 'POST':
        return JsonResponse({'data': 'created'})

Современный подход

from rest_framework import generics

class BookListCreateView(generics.ListCreateAPIView):
    queryset = Book.objects.all()
    serializer_class = BookSerializer

4. request.GET → request.query_params

Старый подход

# Django view — работает, но не DRF-стиль
def my_view(request):
    author = request.GET.get('author', '')
    ...

DRF-стиль

class BookView(APIView):
    def get(self, request):
        author = request.query_params.get('author', '')
        ...

request.query_params — это псевдоним request.GET в DRF, но семантически чище в контексте API.

5. Ручной JSON-парсинг → request.data

Старый подход

import json

def create_book(request):
    data = json.loads(request.body)
    title = data.get('title')
    ...

DRF-стиль

@api_view(['POST'])
def create_book(request):
    serializer = BookSerializer(data=request.data)
    # request.data уже распарсен DRF
    ...

6. Множество сериализаторов → один универсальный

Из лекции (много классов)

class BookListSerializer(ModelSerializer):
    class Meta:
        model = Book
        fields = ['id', 'title', 'author']

class BookDetailSerializer(ModelSerializer):
    class Meta:
        model = Book
        fields = '__all__'

class BookCreateSerializer(ModelSerializer):
    class Meta:
        model = Book
        fields = ['title', 'author', 'price']

Современный подход

class BookSerializer(ModelSerializer):
    class Meta:
        model = Book
        fields = '__all__'
        read_only_fields = ['id', 'created_at']

# Или переопределить get_serializer_class()
# в ViewSet для разных действий
⚠️ Проверить по документации: для крупных проектов разные сериализаторы для list/detail/create — это нормальный паттерн. Единый сериализатор оправдан для небольших API.