Django REST Framework: Какие вопросы зададут опытному специалисту на собеседовании?

Django REST Framework (DRF) стал де-факто стандартом для создания RESTful API на Django. Для Middle и Senior разработчиков собеседование по DRF выходит далеко за рамки базовых концепций. От вас ожидают глубокого понимания архитектуры, возможностей кастомизации, вопросов производительности и лучших практик. Давайте разберем ключевые области, по которым могут задать вопросы опытному специалисту.

Общие вопросы по Django REST Framework

Эти вопросы проверяют ваше общее понимание принципов REST и архитектуры DRF.

Архитектура REST API и принципы проектирования

• Принципы REST: Расскажите о ключевых принципах REST (Statelessness, Client-Server, Cacheable, Uniform Interface, Layered System). Как DRF помогает им следовать? Особое внимание уделите Statelessness – как вы обеспечиваете его в своих API? Приведите примеры идемпотентных и неидемпотентных методов HTTP.
• Проектирование ресурсов: Как вы подходите к проектированию URL-адресов для ресурсов? Обсудите соглашения по именованию, использование множественного/единственного числа, вложенность ресурсов и ее недостатки.
• HATEOAS: Что это такое и почему это важно для REST API? Как можно реализовать HATEOAS с использованием DRF?

Основные компоненты DRF: Serializers, ViewSets, Routers

• Взаимодействие компонентов: Опишите жизненный цикл запроса в DRF, начиная от получения HTTP-запроса и заканчивая отправкой ответа. Какую роль на каждом этапе играют Router, ViewSet, Serializer, Authentication, Permissions, Throttling?
• Гибкость компонентов: В каких случаях вы бы отказались от использования ViewSet в пользу APIView? Когда стандартного Router недостаточно и как его можно расширить или заменить?

Аутентификация и авторизация в DRF (JWT, OAuth)

• Сравнение механизмов: Сравните TokenAuthentication, SessionAuthentication, JWT (JSON Web Tokens) и OAuth2. В каких сценариях каждый из них предпочтительнее? Обсудите плюсы и минусы JWT, особенно вопросы безопасности (хранение токенов, отзыв токенов, время жизни, refresh токены).
• Кастомные Permissions: Приведите примеры создания сложных кастомных классов разрешений. Как реализовать разрешения на уровне объекта (has_object_permission)? Как комбинировать несколько классов разрешений?
• OAuth2 Потоки: Опишите различные потоки авторизации OAuth2 (Authorization Code, Implicit, Resource Owner Password Credentials, Client Credentials) и их применимость.

Вопросы, касающиеся Serializers

Serializer-ы – сердце DRF, и здесь ожидается глубокое понимание.

Кастомизация Serializer-ов: Валидация данных и поля только для чтения

• Продвинутая валидация: Как реализовать валидацию, зависящую от нескольких полей (validate метод)? Как написать кастомные валидаторы для полей (validators атрибут)? Когда использовать serializers.ValidationError?
• Динамические поля: Как можно динамически изменять набор полей serializer-а в зависимости от контекста (например, роли пользователя или типа запроса)? Расскажите про переопределение __init__ или использование метода get_fields.
• read_only_fields vs write_only_fields: Объясните разницу и приведите сценарии использования write_only_fields (например, поля пароля).

Использование SerializerMethodField и Source Field

• SerializerMethodField: Приведите нетривиальные примеры использования SerializerMethodField. Например, агрегация данных из связанных моделей или вычисление значения на основе нескольких полей модели. Как оптимизировать запросы внутри get_<field_name> методов?

from rest_framework import serializers
from django.db.models import Avg, Count
from typing import Dict, Any, Optional

from .models import Product, Review

class ProductAnalyticsSerializer(serializers.ModelSerializer):
    """Сериализатор для вывода аналитики по продукту."""
    average_rating = serializers.SerializerMethodField()
    reviews_count = serializers.SerializerMethodField()

    class Meta:
        model = Product
        fields = ('id', 'name', 'average_rating', 'reviews_count')

    def get_average_rating(self, obj: Product) -> Optional[float]:
        """Вычисляет средний рейтинг на основе отзывов.

        Args:
            obj: Экземпляр модели Product.

        Returns:
            Средний рейтинг или None, если отзывов нет.
        """
        # Оптимизация: Используем annotate в get_queryset во ViewSet,
        # чтобы избежать N+1 запросов.
        if hasattr(obj, 'annotated_avg_rating'):
            return obj.annotated_avg_rating
        # Фоллбэк, если аннотация не была добавлена (менее оптимально)
        return obj.reviews.aggregate(Avg('rating'))['rating__avg']

    def get_reviews_count(self, obj: Product) -> int:
        """Возвращает количество отзывов.

        Args:
            obj: Экземпляр модели Product.

        Returns:
            Количество отзывов.
        """
        if hasattr(obj, 'annotated_reviews_count'):
            return obj.annotated_reviews_count
        return obj.reviews.count()

# Пример использования аннотации во ViewSet:
# queryset = Product.objects.annotate(
#     annotated_avg_rating=Avg('reviews__rating'),
#     annotated_reviews_count=Count('reviews')
# )

• Параметр source: Как использовать source для доступа к атрибутам связанных моделей (source='related_model.field') или для вызова методов модели (source='get_full_name')? Какие могут быть проблемы с производительностью при использовании source?

Вложенные Serializer-ы и работа с отношениями

• Запись вложенных данных: Как обрабатывать запись (создание/обновление) данных через вложенные serializer-ы (nested serializers)? Расскажите о переопределении методов create() и update() родительского serializer-а. Какие есть альтернативы (например, использование PrimaryKeyRelatedField с последующей обработкой во view)?
• Производительность: Вложенные serializer-ы могут приводить к проблеме N+1 запросов при чтении. Как ее решить? (Использование select_related и prefetch_related в get_queryset view).
• Глубина вложенности (depth): Объясните, как работает атрибут Meta.depth. Почему его использование часто считается плохой практикой для сложных API?

ViewSets и работа с запросами

ViewSet-ы упрощают создание CRUD-интерфейсов, но требуют понимания для кастомизации.

Различия между ModelViewSet, ReadOnlyModelViewSet и ViewSet

• Выбор базового класса: В каких ситуациях вы бы выбрали GenericViewSet в сочетании с mixins вместо ModelViewSet? Когда целесообразно использовать базовый ViewSet и определять все методы (actions) вручную?
• Кастомные actions: Как добавить кастомные действия (actions) к ViewSet с помощью декоратора @action? Как настроить для них detail, methods, url_path, permission_classes, throttle_classes?

Кастомизация QuerySet-ов и фильтрация данных

• get_queryset(): Расскажите о типичных сценариях переопределения get_queryset(). Например, фильтрация данных на основе текущего пользователя (self.request.user), параметров запроса или других условий.
• Фильтрация: Сравните различные способы фильтрации: использование filter_backends (DjangoFilterBackend, SearchFilter, OrderingFilter), написание собственных бэкендов фильтрации. Как реализовать сложную логику фильтрации с использованием библиотеки django-filter?
• Аннотации и агрегации: Как использовать .annotate() и .aggregate() внутри get_queryset() для добавления вычисляемых полей или агрегированных данных без использования SerializerMethodField?

Обработка исключений и ошибок в ViewSets

• Стандартные исключения DRF: Какие стандартные исключения предоставляет DRF (NotFound, PermissionDenied, ValidationError, NotAuthenticated и др.) и как они маппятся на HTTP статусы?
• Кастомные обработчики исключений: Как написать и подключить собственный обработчик исключений (EXCEPTION_HANDLER в настройках DRF) для стандартизации формата ошибок во всем API или для обработки специфичных для вашего приложения исключений?

from rest_framework.views import exception_handler
from rest_framework.response import Response
from rest_framework import status
from typing import Optional, Any, Dict

def custom_exception_handler(exc: Exception, context: Dict[str, Any]) -> Optional[Response]:
    """Кастомный обработчик исключений для API.

    Логирует исключение и возвращает стандартизированный формат ошибки.
    """
    # Сначала вызываем стандартный обработчик DRF,
    # чтобы получить стандартный ответ (или None)
    response = exception_handler(exc, context)

    # Если стандартный обработчик обработал исключение
    if response is not None:
        # Можно добавить кастомную логику форматирования
        custom_data = {'detail': response.data}
        if response.status_code == status.HTTP_400_BAD_REQUEST and isinstance(response.data, dict):
            # Более детальная информация для ValidationError
            custom_data['errors'] = response.data
            custom_data['detail'] = 'Ошибка валидации'
        elif response.status_code >= 500:
            # Логируем серверные ошибки
            # logger.error(f"Server error occurred: {exc}", exc_info=True)
            custom_data['detail'] = 'Внутренняя ошибка сервера. Пожалуйста, попробуйте позже.'

        response.data = {'status': 'error', 'message': custom_data['detail'], 'errors': custom_data.get('errors')}

    # Можно добавить обработку специфичных исключений приложения
    # elif isinstance(exc, MySpecificException):
    #     return Response(...)

    return response

# settings.py
# REST_FRAMEWORK = {
#     'EXCEPTION_HANDLER': 'path.to.custom_exception_handler'
# }

Продвинутые темы Django REST Framework

Эти темы часто отличают Senior-разработчика.

Версионирование API

• Зачем нужно версионирование? Объясните необходимость версионирования API.
• Способы версионирования: Сравните различные стратегии версионирования, предоставляемые DRF (URLPathVersioning, NamespaceVersioning, HostNameVersioning, QueryParameterVersioning, AcceptHeaderVersioning). Каковы их плюсы, минусы и типичные случаи использования? Как управлять кодовой базой при наличии нескольких версий API?

Throttling и Rate Limiting

• Назначение: Для чего используется Throttling? Какие проблемы он решает?
• Классы Throttling: Расскажите о встроенных классах (AnonRateThrottle, UserRateThrottle, ScopedRateThrottle). Как определить разные лимиты для разных представлений или действий с помощью ScopedRateThrottle?
• Кастомные Throttles: Как создать собственный класс Throttling, например, для ограничения скорости на основе IP-адреса или API-ключа, хранящегося в кастомной модели?

Документирование API (Swagger, OpenAPI)

• Инструменты: Какие инструменты вы использовали для генерации документации OpenAPI (Swagger) для DRF (drf-yasg, drf-spectacular)? Сравните их.
• Кастомизация схемы: Как кастомизировать генерируемую схему? Например, добавить описание для полей, пометить параметры как обязательные/опциональные, описать возможные ответы (включая ошибки), добавить примеры запросов/ответов.

Тестирование API с использованием DRF

• Инструменты: Как вы тестируете API, созданные с помощью DRF? Расскажите об использовании APIRequestFactory и APIClient.
• Стратегии тестирования: Какие виды тестов вы пишете (unit-тесты для serializer-ов, интеграционные тесты для views)? Как тестировать аутентификацию, разрешения, валидацию, обработку ошибок, пагинацию, фильтрацию?
• Примеры тестов: Напишите пример теста для проверки создания ресурса через POST-запрос, включая проверку статус-кода, данных ответа и состояния базы данных.

Производительность и оптимизация DRF

Оптимизация – ключевой навык для опытного разработчика.

Кэширование данных

• Уровни кэширования: Где и как можно применять кэширование в связке с DRF? (Кэширование на уровне view, кэширование результатов get_queryset, использование django-cache-machine или django-cachalot, кэширование на уровне HTTP с использованием заголовков Cache-Control, ETag).
• Инвалидация кэша: Как решаются проблемы инвалидации кэша при изменении данных?

Оптимизация запросов к базе данных (selectrelated, prefetchrelated)

• Проблема N+1: Объясните суть проблемы N+1 запросов в контексте DRF (особенно с вложенными serializer-ами или при доступе к связанным моделям во view/serializer-ах).
• select_related vs prefetch_related: Когда использовать select_related, а когда prefetch_related? Приведите примеры их использования в get_queryset для оптимизации запросов к связанным моделям (OneToOne, ForeignKey, ManyToMany).
• Анализ запросов: Какие инструменты вы используете для анализа и профилирования запросов к БД (Django Debug Toolbar, django-silk, EXPLAIN ANALYZE)?

Использование Celery для асинхронных задач

• Сценарии использования: В каких случаях целесообразно выносить задачи из цикла запрос-ответ API в фоновые задачи с помощью Celery? (Отправка email/SMS, обработка загруженных файлов, генерация отчетов, взаимодействие с внешними медленными сервисами).
• Интеграция: Как организовать взаимодействие между DRF view и задачей Celery? Как сообщить клиенту API о статусе выполнения фоновой задачи?

from rest_framework import viewsets, status
from rest_framework.response import Response
from rest_framework.decorators import action
from celery.result import AsyncResult

from .models import Report
from .serializers import ReportSerializer
from .tasks import generate_report_task # Импорт задачи Celery

class ReportViewSet(viewsets.ModelViewSet):
    queryset = Report.objects.all()
    serializer_class = ReportSerializer

    @action(detail=False, methods=['post'])
    def generate(self, request):
        """Запускает асинхронную генерацию отчета."""
        # Валидация параметров запроса (если нужны)
        # ...

        # Запускаем задачу Celery
        task: AsyncResult = generate_report_task.delay(user_id=request.user.id)

        # Возвращаем ID задачи для отслеживания статуса
        return Response({'task_id': task.id}, status=status.HTTP_202_ACCEPTED)

    @action(detail=False, methods=['get'], url_path='status/(?P<task_id>[\w-]+)')
    def status(self, request, task_id: str = None):
        """Проверяет статус выполнения задачи Celery."""
        if not task_id:
            return Response({'error': 'Task ID is required'}, status=status.HTTP_400_BAD_REQUEST)

        task_result = AsyncResult(task_id)

        response_data = {
            'task_id': task_id,
            'status': task_result.status,
            'result': task_result.result if task_result.successful() else None
        }

        if task_result.failed():
             response_data['error'] = str(task_result.result) # или traceback

        return Response(response_data, status=status.HTTP_200_OK)

Заключение

Подготовка к собеседованию на позицию Middle/Senior Django-разработчика с фокусом на DRF требует не только знания основ, но и глубокого понимания продвинутых концепций, узких мест производительности и лучших практик проектирования. Умение объяснить сложные темы, привести примеры из опыта и продемонстрировать навыки решения проблем – ключ к успешному прохождению интервью.