to_internal_value()

Предположим, сервисы, использующие наш API, добавляют ненужные данные в конечную точку при создании ресурсов:

 {
   "Информация": {
       "дополнительно": "данные",
       ...
   },
   "ресурс": {
      "идентификатор": 1,
      "title": "C++ с примерами",
      "content": "Это контент ресурса. ",
      "нравится_by": [
         2,
         3
      ],
      "нравится": 2
   }
}
 

Если мы попытаемся сериализовать эти данные, наш сериализатор выйдет из строя, поскольку он не сможет извлечь ресурс.

Мы можем переопределить to_internal_value() для извлечения данных ресурса:

 из сериализаторов импорта rest_framework
из examples.models импортировать ресурс
класс ResourceSerializer (сериализаторы.ModelSerializer):
    Мета класса:
        модель = ресурс
        поля = '__all__'
    def to_internal_value (я, данные):
        resource_data = данные ['ресурс']
        вернуть super().to_internal_value(resource_data)
 

Ура! Наш сериализатор теперь работает как положено.

Serializer Save

Вызов save() либо создаст новый экземпляр, либо обновит существующий экземпляр, в зависимости от того, был ли передан существующий экземпляр при создании экземпляра класса сериализатора:

 # это создает новый экземпляр
сериализатор = MySerializer (данные = данные)
# это обновляет существующий экземпляр
сериализатор = MySerializer (экземпляр, данные = данные)
 

Передача данных непосредственно для сохранения

Иногда вам может понадобиться передать дополнительные данные в момент сохранения экземпляра. Эти дополнительные данные могут включать такую ​​информацию, как текущий пользователь, текущее время или данные запроса.

Вы можете сделать это, включив дополнительные аргументы ключевого слова при вызове save() . Например:

 serializer.save(владелец=request.user)
 

Имейте в виду, что значения, переданные в save() , не будут проверены.

Контекст сериализатора

В некоторых случаях вам необходимо передать дополнительные данные вашим сериализаторам. Это можно сделать с помощью свойства сериализатора контекста . Затем вы можете использовать эти данные внутри сериализатора, например to_representation или при проверке данных.

Вы передаете данные в виде словаря через контекст ключевое слово:

 из сериализаторов импорта rest_framework
из examples.models импортировать ресурс
ресурс = Resource.objects.get(id=1)
сериализатор = ResourceSerializer (ресурс, контекст = {'ключ': 'значение'})
 

Затем вы можете получить его внутри класса сериализатора из словаря self. context следующим образом:

 из сериализаторов импорта rest_framework
из examples.models импортировать ресурс
класс ResourceSerializer (сериализаторы.ModelSerializer):
    Мета класса:
        модель = ресурс
        поля = '__all__'
    def to_representation (я, экземпляр):
        представление = super().to_representation(экземпляр)
        представление['ключ'] = self.context['ключ']
        возвратное представление
 

Выходные данные нашего сериализатора теперь будут содержать ключ со значением .

Исходное ключевое слово

Сериализатор DRF поставляется с исходным ключевым словом , которое является чрезвычайно мощным и может использоваться в различных сценариях. Мы можем использовать его для:

1. Переименовать поля вывода сериализатора
2. Прикрепить ответ функции сериализатора к данным
3. Получение данных от моделей один к одному

Допустим, вы создаете социальную сеть, и у каждого пользователя есть свои UserProfile , который имеет отношение один к одному с моделью User :

 from django. contrib.auth.models import User
из моделей импорта django.db
класс UserProfile (модели.Модель):
    user = models.OneToOneField(to=User, on_delete=models.CASCADE)
    био = модели.TextField()
    рождения_дата = модели.DateField()
    защита __str__(я):
        вернуть профиль f'{self.user.username}'
 

Мы используем ModelSerializer для сериализации наших пользователей:

 класс UserSerializer(сериализаторы.ModelSerializer):
    Мета класса:
        модель = пользователь
        fields = ['id', 'имя пользователя', 'электронная почта', 'is_staff', 'is_active']
 

Сериализуем пользователя:

 {
   "идентификатор": 1,
   "имя пользователя": "админ",
   "email": "[электронная почта защищена]",
   "is_staff": правда,
   "is_active": правда
}
 

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

Чтобы переименовать поле вывода сериализатора, нам нужно добавить новое поле в наш сериализатор и передать его в поля свойство.

 класс UserSerializer (сериализаторы.ModelSerializer):
    активный = сериализаторы.BooleanField (источник = 'is_active')
    Мета класса:
        модель = пользователь
        fields = ['id', 'имя пользователя', 'электронная почта', 'is_staff', 'активный']
 

Наше активное поле теперь будет называться active вместо is_active .

Прикрепить ответ функции сериализатора к данным

Мы можем использовать источник , чтобы добавить поле, равное возвращаемому функцией.

 класс UserSerializer(сериализаторы.ModelSerializer):
    полное_имя = сериализаторы.CharField(источник='get_full_name')
    Мета класса:
        модель = пользователь
        fields = ['id', 'имя пользователя', 'полное_имя', 'электронная почта', 'is_staff', 'активный']
 

get_full_name() — это метод пользовательской модели Django, который объединяет user.first_name и user.last_name .

Теперь наш ответ будет содержать full_name .

Добавление данных из моделей один к одному

Теперь давайте предположим, что мы также хотим включить bio и birth_date нашего пользователя в UserSerializer . Мы можем сделать это, добавив дополнительные поля в наш сериализатор с ключевым словом source.

Давайте изменим наш класс сериализатора:

 класс UserSerializer(serializers.ModelSerializer):
    био = сериализаторы.CharField (источник = 'userprofile.bio')
    Birthday_date = сериализаторы.DateField (источник = 'userprofile.birth_date')
    Мета класса:
        модель = пользователь
        поля = [
            'id', 'имя пользователя', 'электронная почта', 'is_staff',
            'is_active', 'био', 'дата_рождения'
        ] # обратите внимание, мы также добавили сюда новые поля
 

Мы можем получить доступ к пользовательскому профилю.<имя_поля> , потому что это отношение один к одному с нашим пользователем.

Это наш окончательный ответ JSON:

 {
   "идентификатор": 1,
   "имя пользователя": "админ",
   "электронная почта": "",
   "is_staff": правда,
   "is_active": правда,
   "bio": "Это моя биография.",
   "дата_рождения": "1995-04-27"
}
 

SerializerMethodField

SerializerMethodField — это поле, доступное только для чтения, которое получает свое значение путем вызова метода класса сериализатора, к которому оно прикреплено. Его можно использовать для присоединения любых данных к сериализованному представлению объекта.

SerializerMethodField получает свои данные, вызывая get_ .

Если бы мы хотели добавить атрибут full_name в наш сериализатор User , мы могли бы добиться этого следующим образом:

 from django.contrib.auth.models import User
из сериализаторов импорта rest_framework
класс UserSerializer (сериализаторы.ModelSerializer):
    полное_имя = сериализаторы. SerializerMethodField()
    Мета класса:
        модель = пользователь
        поля = '__all__'
    def get_full_name (я, объект):
        вернуть f'{obj.first_name} {obj.last_name}'
 

Этот фрагмент кода создает пользовательский сериализатор, который также содержит full_name , который является результатом функции get_full_name() .

Различные сериализаторы чтения и записи

Если ваши сериализаторы содержат много вложенных данных, которые не требуются для операций записи, вы можете повысить производительность API, создав отдельные сериализаторы чтения и записи.

Вы делаете это, переопределяя метод get_serializer_class() в вашем ViewSet вот так:

 из rest_framework импортирует наборы представлений
из .models импортировать MyModel
из .serializers импортировать MyModelWriteSerializer, MyModelReadSerializer
класс MyViewSet(viewsets.ModelViewSet):
    набор запросов = МояМодель.objects.all()
    деф get_serializer_class (я):
        если self. action в ["создать", "обновить", "partial_update", "уничтожить"]:
            вернуть MyModelWriteSerializer
        вернуть MyModelReadSerializer
 

Этот код проверяет, какая операция REST использовалась, и возвращает MyModelWriteSerializer для операций записи и MyModelReadSerializer для операций чтения.

Поля только для чтения

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

 из сериализаторов импорта rest_framework
класс AccountSerializer(serializers.Serializer):
    id = IntegerField (метка = 'ID', read_only = True)
    имя пользователя = CharField (max_length = 32, требуется = True)
 

Установка таких полей, как id , create_date и т. д. только для чтения, повысит производительность во время операций записи.

Если вы хотите установить для нескольких полей значение read_only , вы можете указать их с помощью read_only_fields в Meta следующим образом:

 из сериализаторов импорта rest_framework
класс AccountSerializer(serializers.Serializer):
    id = IntegerField (метка = 'ID')
    имя пользователя = CharField (max_length = 32, требуется = True)
    Мета класса:
        read_only_fields = ['идентификатор', 'имя пользователя']
 

Вложенные сериализаторы

Существует два разных способа обработки вложенной сериализации с помощью ModelSerializer :

1. Явное определение
2. Использование поля глубины

Явное определение

Явное определение работает путем передачи внешнего Serializer в качестве поля нашему основному сериализатору.

Давайте рассмотрим пример. У нас есть комментарий , который определяется так:

 из импорта пользователя django. contrib.auth.models
из моделей импорта django.db
класс Комментарий (модели.Модель):
    автор = models.ForeignKey(to=User, on_delete=models.CASCADE)
    datetime = models.DateTimeField (auto_now_add = True)
    содержимое = модели.TextField()
 

Допустим, у вас есть следующий сериализатор:

 из сериализаторов импорта rest_framework
класс CommentSerializer(serializers.ModelSerializer):
    автор = UserSerializer()
    Мета класса:
        модель = комментарий
        поля = '__all__'
 

Если мы сериализуем Comment , вы получите следующий вывод:

 {
    "идентификатор": 1,
    "datetime": "2021-03-19T21:51:44.775609Z",
    "content": "Это интересное сообщение.",
    "автор": 1
}
 

Если мы также хотим сериализовать пользователя (вместо того, чтобы показывать только его идентификатор), мы можем добавить поле сериализатора author в наш комментарий :

 из сериализаторов импорта rest_framework
класс UserSerializer (сериализаторы. ModelSerializer):
    Мета класса:
        модель = пользователь
        поля = ['id', 'имя пользователя']
класс CommentSerializer(serializers.ModelSerializer):
    автор = UserSerializer()
    Мета класса:
        модель = комментарий
        поля = '__all__'
 

Повторите сериализацию, и вы получите следующее:

 {
    "идентификатор": 1,
    "автор": {
        "идентификатор": 1,
        "имя пользователя": "админ"
    },
    "datetime": "2021-03-19T21:51:44.775609Z",
    "content": "Это интересное сообщение."
}
 

Использование поля depth

Когда дело доходит до вложенной сериализации, поле depth является одной из самых мощных функций. Предположим, у нас есть три модели — ModelA , ModelB и ModelC 9.0004 . ModelA зависит от ModelB , а ModelB зависит от ModelC . Они определены так:

 из моделей импорта django.db
класс ModelC (модели.Модель):
    содержимое = модели. CharField(max_length=128)
класс ModelB (модели.Модель):
    model_c = models.ForeignKey(to=ModelC, on_delete=models.CASCADE)
    содержимое = модели.CharField(max_length=128)
класс ModelA (модели.Модель):
    model_b = models.ForeignKey(to=ModelB, on_delete=models.CASCADE)
    содержимое = модели.CharField(max_length=128)
 

Наш сериализатор ModelA , который является объектом верхнего уровня, выглядит так:

 из сериализаторов импорта rest_framework
класс ModelASerializer (сериализаторы.ModelSerializer):
    Мета класса:
        модель = МодельА
        поля = '__all__'
 

Если мы сериализуем пример объекта, мы получим следующий вывод:

 {
    "идентификатор": 1,
    "контент": "Контент",
    "модель_б": 1
}
 

Теперь предположим, что мы также хотим включить содержимое ModelB при сериализации Модель А . Мы могли бы добавить явное определение в наш ModelASerializer или использовать поле depth .

Когда мы меняем depth на 1 в нашем сериализаторе следующим образом:

 из сериализаторов импорта rest_framework
класс ModelASerializer (сериализаторы.ModelSerializer):
    Мета класса:
        модель = МодельА
        поля = '__all__'
        глубина = 1
 

Вывод изменится на следующий:

 {
    "идентификатор": 1,
    "контент": "Контент",
    "модель_б": {
        "идентификатор": 1,
        "контент": "Б контент",
        "модель_с": 1
    }
}
 

Если мы изменим его на 2 , наш сериализатор сериализует уровень глубже:

 {
    "идентификатор": 1,
    "контент": "Контент",
    "модель_б": {
        "идентификатор": 1,
        "контент": "Б контент",
        "модель_с": {
            "идентификатор": 1,
            "content": "C-контент"
        }
    }
}
 

Недостатком является то, что вы не можете контролировать сериализацию дочерних элементов. Другими словами, при использовании глубины будут включены все поля дочерних элементов.

Заключение

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

Краткое изложение того, что мы рассмотрели:

Парсеры — Django REST framework

парсеры. py

Веб-сервисы, взаимодействующие с компьютером, как правило, используют больше структурированные форматы для отправки данных, чем закодированные в форме, поскольку они отправка более сложных данных, чем простые формы

— Малкольм Трединник, группа разработчиков Django

Платформа REST включает ряд встроенных классов Parser, которые позволяют принимать запросы с различными типами носителей. Существует также поддержка для определения ваших собственных пользовательских парсеров, что дает вам гибкость в разработке типов мультимедиа, которые принимает ваш API.

Набор допустимых парсеров для представления всегда определяется как список классов. При доступе к request.data платформа REST проверит заголовок Content-Type во входящем запросе и определит, какой синтаксический анализатор использовать для анализа содержимого запроса.

Примечание . При разработке клиентских приложений всегда помните, что при отправке данных в HTTP-запросе необходимо установить заголовок Content-Type .

Если не указать тип содержимого, большинство клиентов по умолчанию будут использовать 'application/x-www-form-urlencoded' , что может быть не тем, что вы хотели.

Например, если вы отправляете закодированные данные json с помощью jQuery с методом .ajax(), обязательно включите настройку contentType: 'application/json' .

Набор синтаксических анализаторов по умолчанию может быть установлен глобально с помощью настройки DEFAULT_PARSER_CLASSES . Например, следующие настройки разрешат только запросы с содержимым JSON вместо стандартных данных JSON или формы.

 REST_FRAMEWORK = {
    'DEFAULT_PARSER_CLASSES': [
        'rest_framework.parsers.JSONParser',
    ]
}
 

Вы также можете установить синтаксические анализаторы, используемые для отдельного представления или набора представлений, с использованием представлений на основе классов APIView .

 из rest_framework. parsers импортирует JSONParser
из rest_framework.response импортировать ответ
из rest_framework.views импортировать APIView
класс ExampleView (APIView):
    """
    Представление, которое может принимать запросы POST с содержимым JSON.
    """
    parser_classes = [JSONParser]
    сообщение о защите (я, запрос, формат = нет):
        вернуть ответ ({'полученные данные': request.data})
 

Или, если вы используете декоратор @api_view с представлениями на основе функций.

 из rest_framework.decorators импортирует api_view
из rest_framework.decorators импортировать parser_classes
из rest_framework.parsers импортировать JSONParser
@api_view(['POST'])
@parser_classes([JSONParser])
def example_view (запрос, формат = нет):
    """
    Представление, которое может принимать запросы POST с содержимым JSON.
    """
    вернуть ответ ({'полученные данные': request.data})
 

Парсы Содержимое запроса JSON . request.data будет заполнен словарем данных.

.media_type : application/json

Разбирает содержимое формы HTML. request.data будет заполнен QueryDict данных.

Как правило, вы хотите использовать вместе FormParser и MultiPartParser , чтобы полностью поддерживать данные форм HTML.

.media_type : application/x-www-form-urlencoded

Разбирает содержимое составной HTML-формы, которая поддерживает загрузку файлов. Оба request.data будут заполнены QueryDict .

Как правило, вы хотите использовать вместе FormParser и MultiPartParser , чтобы полностью поддерживать данные форм HTML.

.media_type : multipart/form-data

Разбирает необработанный контент загружаемого файла. request.data будет словарем с одним ключом 'file' , содержащим загруженный файл.

Если представление, используемое с FileUploadParser , вызывается с аргументом ключевого слова имя файла URL, то этот аргумент будет использоваться в качестве имени файла.

Если он вызывается без аргумента ключевого слова имени файла URL, то клиент должен установить имя файла в HTTP-заголовке Content-Disposition . Например, Content-Disposition: вложение; имя_файла=upload.jpg .

.media_type : */*

Примечания:

• FileUploadParser предназначен для использования с собственными клиентами, которые могут загружать файл как запрос необработанных данных. Для веб-загрузок или для собственных клиентов с поддержкой многокомпонентной загрузки вместо этого следует использовать MultiPartParser .
• Поскольку media_type этого синтаксического анализатора соответствует любому типу контента, FileUploadParser обычно должен быть единственным синтаксическим анализатором, установленным в представлении API. /]+)$', FileUploadView.as_view()) ]

  ---

  Чтобы реализовать собственный синтаксический анализатор, вы должны переопределить BaseParser , установить свойство .media_type и реализовать метод .parse(self, stream, media_type, parser_context) .

  Метод должен возвращать данные, которые будут использоваться для заполнения свойства request.data .

  Аргументы, переданные в .parse() :

  поток

  Потоковой объект, представляющий тело запроса.

  media_type

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

  В зависимости от заголовка запроса Content-Type: он может быть более конкретным, чем атрибут media_type средства визуализации , и может включать параметры типа мультимедиа. Например, "text/plain; charset=utf-8" .

  parser_context

  Необязательно. Если указан, этот аргумент будет словарем, содержащим любой дополнительный контекст, который может потребоваться для анализа содержимого запроса.

  По умолчанию это будет включать следующие ключи: view , request , args , kwargs .

  Ниже приведен пример анализатора открытого текста, который заполняет свойство request.data строкой, представляющей тело запроса.

   класс PlainTextParser (BaseParser):
      """
      Парсер простого текста.
      """
      media_type = 'текст/обычный'
      def parse(self, stream, media_type=None, parser_context=None):
          """
          Просто верните строку, представляющую тело запроса.
          """
          возвратный поток.read()
   

  ---

  Также доступны следующие сторонние пакеты.

  Платформа REST YAML обеспечивает поддержку синтаксического анализа и рендеринга YAML. Ранее он был включен непосредственно в пакет инфраструктуры REST, а теперь вместо этого поддерживается как сторонний пакет.

  Установка и настройка

  Установить с помощью pip.

   $ pip установить djangorestframework-yaml
   

  Измените настройки среды REST.