Django REST Framework: Как реализовать поля только для записи?

При разработке RESTful API с использованием Django REST Framework (DRF) часто возникает потребность в тонком контроле над тем, какие данные могут быть прочитаны из ресурса, а какие – только записаны в него. Стандартное поведение полей сериализатора позволяет как чтение, так и запись, но для определенных сценариев требуется иная логика.

Что такое поля только для записи и зачем они нужны?

Поля только для записи (write-only fields) в контексте DRF — это поля сериализатора, которые используются при десериализации входных данных (т.е., при обработке запросов POST, PUT, PATCH), но не включаются в сериализованное представление при ответе (GET).

Основная цель таких полей — принимать определенные данные от клиента (например, пароль, подтверждение пароля, временный токен для сброса пароля), которые необходимы для выполнения операции записи или обновления, но которые не должны возвращаться клиенту при последующих запросах на чтение.

Сценарии использования: защита конфиденциальных данных и контроль обновления

Типичные сценарии для полей только для записи включают:

Работа с паролями: При создании или обновлении пользователя клиент отправляет пароль. Этот пароль необходим для сохранения в хешированном виде в базе данных. Однако при получении данных пользователя (например, через GET /users/{id}/) пароль, конечно, не должен быть частью ответа.

Подтверждение данных: Например, поле password_confirmation, которое нужно только при регистрации или смене пароля для проверки совпадения с полем password. Это поле не хранится в базе данных и не возвращается в ответе.

Временные или служебные данные: Ключи API, временные коды подтверждения (OTP) для двухфакторной аутентификации, которые передаются клиентом для верификации, но не являются частью постоянного состояния ресурса.

Контроль зависимых полей: Поле, которое влияет на другие поля при записи, но само по себе не является частью выходного представления ресурса.

Краткий обзор стандартных полей DRF и их поведение

По умолчанию, большинство полей сериализатора в DRF (CharField, IntegerField, BooleanField и т.д.) являются одновременно читаемыми и записываемыми. Это означает, что они используются как при десериализации (из входных данных в Python-объекты), так и при сериализации (из Python-объектов в выходные данные).

Для контроля поведения полей DRF предоставляет несколько флагов:

read_only=True: Поле используется только при сериализации. Значение поля определяется логикой update() или create() сериализатора или берется непосредственно из инстанса объекта. Игнорируется при десериализации.

write_only=True: Поле используется только при десериализации. Игнорируется при сериализации. Это именно то, что нам нужно для рассматриваемых сценариев.

required=True (по умолчанию): Поле обязательно при десериализации.

required=False: Поле опционально при десериализации.

Понимание этих базовых флагов критически важно для эффективной работы с сериализаторами DRF.

Реализация полей только для записи с помощью `extra_kwargs`

Один из наиболее простых и часто используемых способов определения полей только для записи — это использование опции extra_kwargs в мета-классе сериализатора.

Использование `extra_kwargs` для установки `write_only=True`

Опция extra_kwargs представляет собой словарь, где ключами являются имена полей, а значениями — словари с дополнительными аргументами, которые будут применены к соответствующему полю. Это удобный способ переопределить аргументы поля, которые, возможно, были унаследованы (например, из ModelSerializer) или задать специфичные флаги вроде write_only или read_only без явного определения поля в сериализаторе, если оно уже есть в модели.

Чтобы сделать поле только для записи с помощью extra_kwargs, достаточно указать имя поля и передать { 'write_only': True }:

from rest_framework import serializers
from django.contrib.auth import get_user_model

UserModel = get_user_model()

class UserSerializer(serializers.ModelSerializer):
    class Meta:
        model = UserModel
        # Включаем поле 'password', даже если оно не определено явно,
        # чтобы управлять его поведением через extra_kwargs
        fields = ('id', 'username', 'email', 'password')
        extra_kwargs = {
            # Определяем, что поле 'password' будет только для записи
            'password': {'write_only': True, 'min_length': 8}
        }

    def create(self, validated_data: dict) -> UserModel:
        """ Создает нового пользователя с хешированным паролем. """
        # Извлекаем пароль из валидированных данных (он там есть,
        # потому что поле 'password' write_only)
        password = validated_data.pop('password')
        # Создаем пользователя без пароля
        user = UserModel.objects.create(**validated_data)
        # Устанавливаем пароль с использованием встроенного метода set_password
        user.set_password(password)
        user.save()
        return user

    def update(self, instance: UserModel, validated_data: dict) -> UserModel:
        """ Обновляет существующего пользователя, обрабатывая пароль при необходимости. """
        # Проверяем, был ли передан новый пароль в данных для обновления
        password = validated_data.pop('password', None)

        # Обновляем остальные поля пользователя
        for attr, value in validated_data.items():
            setattr(instance, attr, value)

        # Если пароль был передан, обновляем его
        if password is not None:
            instance.set_password(password)

        instance.save()
        return instance

В этом примере поле password включено в fields, но благодаря extra_kwargs оно будет приниматься при POST/PUT/PATCH запросах (и доступно в validated_data), но не будет отображаться в ответе GET. Мы также добавили базовую валидацию min_length через extra_kwargs.

Пример: сокрытие пароля при чтении, но разрешение записи

Как видно из примера выше, extra_kwargs = {'password': {'write_only': True}} эффективно скрывает поле password из выходного JSON при сериализации (например, при просмотре данных пользователя) и делает его доступным в validated_data при десериализации (например, при создании или обновлении пользователя).

Клиент может отправить данные типа {'username': 'testuser', 'email': 'test@example.com', 'password': 'strongpassword'} для создания пользователя. Сериализатор обработает username, email и password. В методе create мы получим все три поля в validated_data. Затем, при запросе GET на данные этого пользователя, DRF сериализует объект UserModel, но поле password будет проигнорировано из-за write_only=True.

Преимущества и ограничения подхода с `extra_kwargs`

Преимущества:

Простота: Самый быстрый способ пометить существующее поле (особенно в ModelSerializer) как только для записи.

Чистота кода: Не требует явного определения поля в классе сериализатора, если оно уже есть в модели и вам нужно только изменить его поведение.

Централизация настроек: Все специфичные аргументы для полей собраны в одном месте (extra_kwargs).

Ограничения:

Нет сложной логики: Вы не можете использовать extra_kwargs для определения сложной логики десериализации или сериализации поля. Для этого нужно определять поле явно.

Только для существующих полей: В основном используется для полей, которые уже присутствуют в модели и включены в fields Meta-класса, но нужно изменить их стандартное поведение.

Создание пользовательских полей только для записи

В некоторых случаях поля только для записи не соответствуют полям модели или требуют специфической логики десериализации (например, для валидации). В таких ситуарах необходимо определить пользовательское поле сериализатора.

Наследование от `serializers.Field` и переопределение методов

Для создания пользовательского поля нужно унаследоваться от serializers.Field (или другого базового класса поля, если это уместно) и переопределить как минимум два метода:

to_internal_value(self, data): Этот метод отвечает за десериализацию данных. Он принимает