Валидаторы

django-rest-framework-russian-documentation
Search…
Валидаторы
Валидаторы
Валидаторы могут быть полезными для переиспользования валидирующей логики для различных полей.
— Django documentation​
Большую часть времени, когда вы имеете дело с валидацией в REST framework, вы просто будете полагаться на валидацию поля по умолчанию или писать явные методы валидации для сериализатора или классов полей.
Однако иногда вы захотите поместить свою логику валидации в повторно используемые компоненты, чтобы ее можно было легко повторно использовать во всей кодовой базе. Этого можно добиться с помощью функций-валидаторов и валидаторов-классов.
Валидация в REST framework
Валидация в сериализаторах Django REST framework обрабатывается немного иначе, чем валидация в классе Django ModelForm.
С помощью ModelForm валидация выполняется частично в форме и частично на экземпляре модели. В REST framework валидация полностью выполняется в классе сериализатора. Это выгодно по следующим причинам:
Это вводит правильное разделение ответственности, делая поведение вашего кода более очевидным.
Легко переключаться между использованием классов ModelSerializer и Serializer. Любое поведение валидации, используемое для ModelSerializer, легко воспроизвести.
Печать repr экземпляра сериализатора покажет вам, какие именно правила валидации он применяет. В экземпляре модели не вызывается дополнительное скрытое поведение валидации.
Когда вы используете ModelSerializer, все это выполняется автоматически. Если вы хотите перейти к использованию классов Serializer вместо этого, вам необходимо явно определить правила валидации.
Пример
В качестве примера того, как REST framework использует явную валидацию, мы возьмем простой класс модели, у которого есть поле с ограничением уникальности.
1
class CustomerReportRecord(models.Model):
2
    time_raised = models.DateTimeField(default=timezone.now, editable=False)
3
    reference = models.CharField(unique=True, max_length=20)
4
    description = models.TextField()
Copied!
Вот базовый ModelSerializer, который мы можем использовать для создания или обновления экземпляров CustomerReportRecord:
1
class CustomerReportSerializer(serializers.ModelSerializer):
2
    class Meta:
3
        model = CustomerReportRecord
Copied!
Если мы откроем оболочку Django с помощью manage.py shell, мы сможем
1
>>> from project.example.serializers import CustomerReportSerializer
2
>>> serializer = CustomerReportSerializer()
3
>>> print(repr(serializer))
4
CustomerReportSerializer():
5
    id = IntegerField(label='ID', read_only=True)
6
    time_raised = DateTimeField(read_only=True)
7
    reference = CharField(max_length=20, validators=[<UniqueValidator(queryset=CustomerReportRecord.objects.all())>])
8
    description = CharField(style={'type': 'textarea'})
Copied!
Интересным моментом здесь является поле reference. Мы видим, что ограничение уникальности явно принудительно применяется валидатором в поле сериализатора.
Из-за этого более явного стиля REST framework включает несколько классов валидаторов, которые недоступны в ядре Django. Эти классы подробно описаны ниже.
UniqueValidator
Этот валидатор можно использовать для принудительного применения ограничения unique=True для полей модели. Он принимает один обязательный аргумент и необязательный аргумент messages:
queryset обязательно - это набор запросов, для которого должна быть применена уникальность.
message - Сообщение об ошибке, которое следует использовать в случае сбоя валидации.
lookup - поиск, используемый для поиска существующего экземпляра с проверяемым значением. По умолчанию - 'exact'.
Этот валидатор должен применяться к полям сериализатора, например:
1
from rest_framework.validators import UniqueValidator
2
​
3
slug = SlugField(
4
    max_length=100,
5
    validators=[UniqueValidator(queryset=BlogPost.objects.all())]
6
)
Copied!
UniqueTogetherValidator
Этот валидатор может использоваться для наложения ограничений unique_together на экземплярах модели. У него есть два обязательных аргумента и один необязательный аргумент messages:
queryset обязательно - это набор запросов, для которого должна быть применена уникальность.
fields обязательно - список или кортеж имен полей, которые должны составлять уникальный набор. Они должны существовать как поля в классе сериализатора.
message - Сообщение об ошибке, которое следует использовать в случае сбоя валидации.
Валидатор должен применяться к классам сериализатора, например:
1
from rest_framework.validators import UniqueTogetherValidator
2
​
3
class ExampleSerializer(serializers.Serializer):
4
    # ...
5
    class Meta:
6
        # ToDo items belong to a parent list, and have an ordering defined
7
        # by the 'position' field. No two items in a given list may share
8
        # the same position.
9
        validators = [
10
            UniqueTogetherValidator(
11
                queryset=ToDoItem.objects.all(),
12
                fields=['list', 'position']
13
            )
14
        ]
Copied!
Примечание: класс UniqueTogetherValidator всегда накладывает неявное ограничение, согласно которому все поля, к которым он применяется, всегда обрабатываются как обязательные. Поля со значением default являются исключением, поскольку они всегда предоставляют значение, даже если они опущены при вводе пользователем.
UniqueForDateValidator
UniqueForMonthValidator
UniqueForYearValidator
Эти валидаторы могут использоваться для обеспечения соблюдения ограничений unique_for_date, unique_for_month и unique_for_year для экземпляров модели. Они принимают следующие аргументы:
queryset обязательно - это набор запросов, для которого должна быть применена уникальность.
field обязательно - имя поля, уникальность которого будет проверяться в заданном диапазоне дат. Оно должно существовать как поле в классе сериализатора.
date_field обязательно - Имя поля, которое будет использоваться для определения диапазона дат для ограничения уникальности. Оно должно существовать как поле в классе сериализатора.
message - Сообщение об ошибке, которое следует использовать в случае сбоя валидации.
Валидатор должен применяться к классам сериализатора, например:
1
from rest_framework.validators import UniqueForYearValidator
2
​
3
class ExampleSerializer(serializers.Serializer):
4
    # ...
5
    class Meta:
6
        # Blog posts should have a slug that is unique for the current year.
7
        validators = [
8
            UniqueForYearValidator(
9
                queryset=BlogPostItem.objects.all(),
10
                field='slug',
11
                date_field='published'
12
            )
13
        ]
Copied!
Поле даты, которое используется для проверки, всегда должно присутствовать в классе сериализатора. Вы не можете просто полагаться на класс модели default=..., потому, что значение, используемое для значения по умолчанию, не будет сгенерировано до тех пор, пока не будет запущена валидация.
Есть несколько стилей, которые вы можете использовать для этого в зависимости от того, как вы хотите, чтобы ваш API вел себя. Если вы используете ModelSerializer, вы, вероятно, просто будете полагаться на значения по умолчанию, которые REST framework генерирует для вас, но если вы используете Serializer или просто хотите более явный контроль, используйте один из стилей, показанных ниже.
Использование с записываемым полем даты.
Если вы хотите, чтобы поле даты было доступным для записи, единственное, что стоит отметить - что вы должны убедиться, что оно всегда доступно во входных данных, либо установив аргумент default, либо установив required=True.
1
published = serializers.DateTimeField(required=True)
Copied!
Использование с полем даты только для чтения.
Если вы хотите, чтобы поле даты было видимым, но не доступным для редактирования пользователем, установите read_only=True и дополнительно установите аргумент default=....
1
published = serializers.DateTimeField(read_only=True, default=timezone.now)
Copied!
Использование со скрытым полем даты.
Если вы хотите, чтобы поле даты было полностью скрыто от пользователя, используйте HiddenField. Этот тип поля не принимает вводимые пользователем данные, но вместо этого всегда возвращает значение по умолчанию для validated_data в сериализаторе.
1
published = serializers.HiddenField(default=timezone.now)
Copied!
Примечание: классы UniqueFor<Range>Validator налагают неявное ограничение, согласно которому поля, к которым они применяются, всегда обрабатываются как требуемые. Поля со значениями default являются исключением, поскольку они всегда предоставляют значение, даже если они опущены при вводе пользователем.
Расширенные значения полей по умолчанию
Валидаторы, которые применяются к нескольким полям в сериализаторе, иногда могут требовать ввода поля, которое не должно предоставляться клиентом API, но которое доступно в качестве входных данных для валидатора.
Два шаблона, которые вы можете использовать для такого рода валидации, включают:
Использование HiddenField. Это поле будет присутствовать в validated_data, но не будет использоваться в выходном представлении сериализатора.
Использование стандартного поля с read_only=True, но оно также включает аргумент default=.... Это поле будет использоваться в выходном представлении сериализатора, но не может быть установлено пользователем напрямую.
REST framework включает в себя несколько значений по умолчанию, которые могут быть полезны в этом контексте.
CurrentUserDefault
Класс по умолчанию, который можно использовать для представления текущего пользователя. Чтобы использовать это, 'request' должен быть предоставлен как часть словаря контекса при создании экземпляра сериализатора.
1
owner = serializers.HiddenField(
2
    default=serializers.CurrentUserDefault()
3
)
Copied!
CreateOnlyDefault
Класс по умолчанию, который может использоваться только для установки аргумента по умолчанию во время операций создания. Во время обновлений поле опускается.
Он принимает единственный аргумент, который является значением по умолчанию или вызываемым, который следует использовать во время операций создания.
1
created_at = serializers.DateTimeField(
2
    default=serializers.CreateOnlyDefault(timezone.now)
3
)
Copied!
Ограничения валидаторов
Есть некоторые неоднозначные случаи, когда вам нужно вместо этого явно обрабатывать валидацию, а не полагаться на классы сериализатора по умолчанию, которые генерирует ModelSerializer.
В этих случаях вы можете захотеть отключить автоматически сгенерированные валидаторы, указав пустой список для атрибута сериализатора Meta.validators.
Необязательные поля
По умолчанию валидация unique_together требует, чтобы все поля были required=True. В некоторых случаях вам может потребоваться явное применение required=False к одному из полей, и в этом случае желаемое поведение валидации будет неоднозначным.
В этом случае вам обычно нужно исключить валидатор из класса сериализатора и вместо этого явно написать любую логику валидации либо в методе .validate(), либо в представлении.
Например:
1
class BillingRecordSerializer(serializers.ModelSerializer):
2
    def validate(self, attrs):
3
        # Apply custom validation either here, or in the view.
4
​
5
    class Meta:
6
        fields = ['client', 'date', 'amount']
7
        extra_kwargs = {'client': {'required': False}}
8
        validators = []  # Remove a default "unique together" constraint.
Copied!
Обновление вложенных сериализаторов
При обновлении существующего экземпляра, валидаторы уникальности исключают текущий экземпляр из валидации. Текущий экземпляр доступен в контексте валидации уникальности, потому что он существует как атрибут в сериализаторе, изначально переданный с помощью instance=... при создании экземпляра сериализатора.
В случае операций обновления на вложенных сериализаторах нет возможности применить это исключение, потому что экземпляр недоступен.
Опять же, вы, вероятно, захотите явно удалить валидатор из класса сериализатора и явно написать код для ограничения валидации в методе .validate() или в представлении.
Отладка сложных случаев
Если вы не уверены, какое именно поведение будет генерировать класс ModelSerializer, обычно рекомендуется запустить оболочку manage.py и напечатать экземпляр сериализатора, чтобы вы могли проверить поля и валидаторы, которые он автоматически создается для вас.
1
>>> serializer = MyComplexModelSerializer()
2
>>> print(serializer)
3
class MyComplexModelSerializer:
4
    my_fields = ...
Copied!
Также имейте в виду, что в сложных случаях часто бывает лучше явно определить классы сериализатора, чем полагаться на поведение по умолчанию ModelSerializer. Это требует немного большего количества кода, но гарантирует, что результирующее поведение будет более прозрачным.
Написание пользовательских валидаторов
Вы можете использовать любой из существующих валидаторов Django или написать свои собственные валидаторы.
На основе функций
A validator may be any callable that raises a serializers.ValidationError on failure.
Валидатором может быть любой вызываемый объект, который вызывает ошибку serializers.ValidationError в случае неудачи.
1
def even_number(value):
2
    if value % 2 != 0:
3
        raise serializers.ValidationError('This field must be an even number.')
Copied!
Валидация на уровне полей
Вы можете указать настраиваемую валидацию на уровне поля, добавив методы .validate_<field_name> к вашему подклассу Serializer. Это описано в Документации по сериализаторам​
Валидация на основе классов
Чтобы написать валидатор на основе классов, используйте метод __call__. Валидаторы на основе классов полезны, поскольку они позволяют параметризировать и повторно использовать поведение.
1
class MultipleOf:
2
    def __init__(self, base):
3
        self.base = base
4
​
5
    def __call__(self, value):
6
        if value % self.base != 0:
7
            message = 'This field must be a multiple of %d.' % self.base
8
            raise serializers.ValidationError(message)
Copied!
Доступ к контексту
В некоторых сложных случаях может потребоваться, чтобы валидатору передавалось поле сериализатора, с которым он используется, в качестве дополнительного контекста. Вы можете сделать это, установив на валидаторе атрибут requires_context=True. Затем будет вызван метод __call__ с параметром serializer_field или serializer в качестве дополнительного аргумента.
1
    requires_context = True
2
​
3
    def __call__(self, value, serializer_field):
4
        ...
Copied!