что такое serializer в django

Django Rest Framework для начинающих: создаём API для чтения данных (часть 2)

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

Важный момент: мы говорим о работе сериалайзера только на чтение, то есть когда он отдаёт пользователю информацию из базы данных (БД) сайта. О работе на запись, когда данные поступают извне и их надо сохранить в БД, расскажем в следующей статье.

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

Как создаётся сериалайзер, работающий на чтение

Создание экземпляра сериалайзера мы описывали следующим образом:

Подробнее о методе many_init :

Помимо many=True мы передали значение для атрибута instance (инстанс). В нём — набор записей из модели.

Важное замечание: чтобы не запутаться и понимать, когда речь идёт о сериалайзере в целом, а когда — о дочернем сериалайзере, далее по тексту мы будем говорить «основной сериалайзер» (в коде контроллера это serializer_for_queryset ) и «дочерний сериалайзер» (атрибут child основного сериалайзера).

После создания основного сериалайзера мы обращаемся к его атрибуту data :

Запускается целый набор операций, каждую из которых подробно рассмотрим далее.

Что под капотом атрибута data основного сериалайзера

Как работает метод to_represantation основного сериалайзера

Сделаем небольшую остановку:

Как работает метод to_representation дочернего сериалайзера

Как запись из модели обрабатывается методами полей сериалайзера

Метод get_attribute работает с инстансом (instance). Важно не путать этот инстанс с инстансом основного сериалайзера. Инстанс основного сериалайзера — это набор записей из модели. Инстанс дочернего сериалайзера — каждая конкретная запись.

Вспомним строку из кода to_representation основного сериалайзера:

Этот item (отдельная запись из набора) и есть инстанс, с которым работает метод get_attribute конкретного поля.

У нас есть такие поля:

Получается следующая картина:

Как мы уже указывали, список source_attrs в качестве аргумента attrs передаётся в метод get_attribute rest_framework.fields :

С author.username ситуация интереснее. До значения атрибута username DRF будет добираться так:

Суммируем всё, что узнали

Преобразованный набор записей из Django-модели доступен в атрибуте data основного сериалайзера. При обращении к этому атрибуту задействуются следующие методы и атрибуты из-под капота DRF (разумеется, эти методы можно переопределить):

В словарь заносится пара «ключ-значение»:

Итог: список из OrderedDict в количестве, равном числу переданных и сериализованных записей из модели.

Надеюсь, статья оказалась полезной и позволила дать картину того, как под капотом DRF происходит сериализация данных из БД. Если у вас остались вопросы, задавайте их в комментариях — разберёмся вместе.

Источник

Сериализация объектов Django ¶

Фреймворк сериализации Django предоставляет механизм для «перевода» моделей Django в другие форматы. Обычно эти другие форматы основаны на тексте и используются для отправки данных Django по сети, но сериализатор может обрабатывать любой формат (текстовый или нет).

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

Сериализация данных ¶

На самом высоком уровне вы можете сериализовать данные следующим образом:

Аргументами serialize функции являются формат для сериализации данных (см. Форматы сериализации ) и формат QuerySet для сериализации. (Фактически, вторым аргументом может быть любой итератор, который возвращает экземпляры модели Django, но почти всегда это будет QuerySet).

django.core.serializers. get_serializer ( формат ) ¶

Вы также можете напрямую использовать объект сериализатора:

Это полезно, если вы хотите сериализовать данные непосредственно в файловый объект (который включает HttpResponse ):

Вызов get_serializer() с неизвестным форматом вызовет django.core.serializers.SerializerDoesNotExist исключение.

Подмножество полей ¶

Если вы хотите сериализовать только подмножество полей, вы можете указать fields аргумент сериализатору:

В этом примере будут сериализованы только атрибуты name и size каждой модели. Первичный ключ всегда сериализуется как pk элемент результирующего вывода; он никогда не появляется в fields детали.

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

Унаследованные модели ¶

Если вы сериализуете только модель ресторана:

поля сериализованного вывода будут содержать только serves_hot_dogs атрибут. name Атрибут базового класса будет игнорироваться.

Чтобы полностью сериализовать ваши Restaurant экземпляры, вам также необходимо сериализовать Place модели:

Десериализация данных ¶

Десериализация данных очень похожа на их сериализацию:

Однако здесь все немного усложняется. Объекты, возвращаемые deserialize итератором , не являются обычными объектами Django. Вместо этого они являются специальными DeserializedObject экземплярами, которые обертывают созданный, но несохраненный объект и любые связанные данные о взаимосвязи.

Вызов DeserializedObject.save() сохраняет объект в базе данных.

Если pk атрибут в сериализованных данных не существует или имеет значение null, новый экземпляр будет сохранен в базе данных.

Это гарантирует, что десериализация будет неразрушающей операцией, даже если данные в вашем сериализованном представлении не соответствуют тому, что в настоящее время находится в базе данных. Обычно работа с этими DeserializedObject экземплярами выглядит примерно так:

Форматы сериализации ¶

Django поддерживает ряд форматов сериализации, некоторые из которых требуют установки сторонних модулей Python:

Базовый формат сериализации XML выглядит так:

В этом примере мы указываем, что auth.Permission объект с PK 27 имеет внешний ключ для contenttypes.ContentType экземпляра с PK 9.

Отношения ManyToMany экспортируются для модели, которая их связывает. Например, auth.User модель имеет такое отношение к auth.Permission модели:

Этот пример связывает данного пользователя с моделями разрешений с PK 46 и 47.

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

Внешние ключи имеют PK связанного объекта как значение свойства. Отношения ManyToMany сериализуются для модели, которая их определяет, и представлены в виде списка PK.

Затем вы можете перейти cls=LazyEncoder к serializers.serialize() функции:

Все данные теперь выгружаются с помощью Unicode. Если вам нужно предыдущее поведение, перейдите ensure_ascii=True к serializers.serialize() функции.

DjangoJSONEncoder ¶

JSONL ¶

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

Ссылочные поля снова представлены PK или последовательностью PK.

Все данные теперь выгружаются с помощью Unicode. Если вам нужно предыдущее поведение, перейдите allow_unicode=False к serializers.serialize() функции.

Натуральные ключи ¶

Стратегия сериализации по умолчанию для внешних ключей и отношений «многие ко многим» заключается в сериализации значения первичного ключа (ов) объектов в отношении. Эта стратегия хорошо работает для большинства объектов, но при некоторых обстоятельствах может вызвать затруднения.

Десериализация естественных ключей ¶

Рассмотрим следующие две модели:

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

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

Однако, если мы добавим к Person естественную обработку ключей, приспособление станет намного более человечным. Чтобы добавить обработку естественного ключа, вы определяете Manager по умолчанию для Person с get_by_natural_key() методом. В случае с человеком хорошим естественным ключом может быть пара имени и фамилии:

Теперь книги могут использовать этот естественный ключ для ссылки на Person объекты:

Когда вы пытаетесь загрузить эти сериализованные данные, Django будет использовать этот get_by_natural_key() метод для преобразования в первичный ключ реального объекта. [«Douglas», «Adams»] Person

Какие бы поля вы ни использовали для естественного ключа, они должны иметь возможность однозначно идентифицировать объект. Обычно это означает, что ваша модель будет иметь условие уникальности (уникальное = True для одного поля или для unique_together нескольких полей) для поля или полей в вашем естественном ключе. Однако уникальность необязательно обеспечивать на уровне базы данных. Если вы уверены, что набор полей будет фактически уникальным, вы все равно можете использовать эти поля в качестве естественного ключа.

Десериализация объектов без первичного ключа всегда будет проверять, есть ли у менеджера модели get_by_natural_key() метод, и если да, то использовать его для заполнения первичного ключа десериализованного объекта.

Сериализация естественных ключей ¶

Если use_natural_foreign_keys=True указано, Django будет использовать этот natural_key() метод для сериализации любой ссылки внешнего ключа на объекты того типа, который определяет метод.

Если use_natural_primary_keys=True указано, Django не будет предоставлять первичный ключ в сериализованных данных этого объекта, поскольку он может быть вычислен во время десериализации:

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

И наоборот, если (по какой-то странной причине) вы хотите, чтобы Django выводил естественные ключи во время сериализации, но не имел возможности загружать эти ключевые значения, просто не определяйте get_by_natural_key() метод.

Естественные ключи и прямые ссылки ¶

Иногда, когда вы используете естественные внешние ключи, вам нужно десериализовать данные, если у объекта есть внешний ключ, ссылающийся на другой объект, который еще не был десериализован. Это называется «прямой ссылкой».

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

Типичное использование выглядит так:

Зависимости при сериализации ¶

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

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

Чтобы управлять этим порядком, вы можете определить зависимости от ваших natural_key() методов. Вы делаете это, устанавливая dependencies атрибут в самом natural_key() методе.

Например, давайте добавим естественный ключ к Book модели из приведенного выше примера:

Это определение гарантирует, что все Person объекты будут сериализованы перед любыми Book объектами. В свою очередь, любой объект реферирование Book будет сериализовать после того, как Person и Book было сериализовать.

Источник

Сериализаторы¶

‒ Russell Keith-Magee, Django users group

Объявление сериализаторов¶

Давайте начнем с создания простого объекта, который мы можем использовать для примера:

Объявление сериализатора очень похоже на объявление формы:

Сериализация объектов¶

Десериализация объектов¶

Десериализация аналогична. Сначала мы разбираем поток на собственные типы данных Python…

затем мы восстанавливаем эти родные типы данных в словарь проверенных данных.

Сохранение экземпляров¶

Если ваши экземпляры объектов соответствуют моделям Django, вы также захотите убедиться, что эти методы сохраняют объект в базе данных. Например, если Comment является моделью Django, методы могут выглядеть следующим образом:

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

Валидация¶

При десериализации списка элементов ошибки будут возвращены в виде списка словарей, представляющих каждый из десериализованных элементов.

Возникновение исключения при недопустимых данных¶

Валидация на полевом уровне¶

Эти методы принимают единственный аргумент, который является значением поля, требующего проверки.

Валидация на уровне объекта¶

Валидаторы¶

Отдельные поля сериализатора могут включать валидаторы, например, путем объявления их в экземпляре поля:

Доступ к исходным данным и экземпляру¶

Частичные обновления¶

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

Работа с вложенными объектами¶

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

Аналогично, если вложенное представление должно быть списком элементов, необходимо передать флаг many=True в сериализатор вложенного представления.

Записываемые вложенные представления¶

При работе с вложенными представлениями, поддерживающими десериализацию данных, любые ошибки с вложенными объектами будут вложены под именем поля вложенного объекта.

В следующем примере показано, как можно создать пользователя с вложенным объектом профиля.

Установите отношение NULL в базе данных.

Удалить связанный экземпляр.

Игнорируйте данные и оставьте экземпляр как есть.

Вызвать ошибку валидации.

Обработка сохранения связанных экземпляров в классах менеджера моделей¶

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

Например, предположим, мы хотим, чтобы экземпляры User и Profile всегда создавались вместе как пара. Мы можем написать пользовательский класс менеджера, который будет выглядеть примерно так:

Работа с несколькими объектами¶

Класс Serializer также может обрабатывать сериализацию или десериализацию списков объектов.

Сериализация нескольких объектов¶

Чтобы сериализовать кверисет или список объектов вместо одного экземпляра объекта, необходимо передать флаг many=True при инстанцировании сериализатора. Затем вы можете передать кверисет или список объектов для сериализации.

Десериализация нескольких объектов¶

Поведение по умолчанию для десериализации нескольких объектов заключается в поддержке создания нескольких объектов, но не в поддержке обновления нескольких объектов. Для получения дополнительной информации о том, как поддерживать или настраивать любой из этих случаев, см. документацию ListSerializer ниже.

Включение дополнительного контекста¶

В некоторых случаях необходимо предоставить сериализатору дополнительный контекст в дополнение к сериализуемому объекту. Одним из распространенных случаев является использование сериализатора, который включает отношения с гиперссылками, что требует, чтобы сериализатор имел доступ к текущему запросу, чтобы он мог правильно генерировать полностью определенные URL.

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

ModelSerializer¶

Часто вам понадобятся классы сериализаторов, которые близко сопоставляются с определениями моделей Django.

Класс ModelSerializer предоставляет ярлык, позволяющий автоматически создать класс Serializer с полями, которые соответствуют полям Модели.

Класс «ModelSerializer« такой же, как и обычный класс «Serializer«, за исключением того, что :

Он автоматически сгенерирует для вас набор полей на основе модели.

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

Объявление ModelSerializer выглядит следующим образом:

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

Указание того, какие поля следует включить¶

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

Имена в атрибутах fields и exclude обычно отображаются на поля модели в классе модели.

Альтернативные имена в опциях fields могут указывать на свойства или методы, не принимающие аргументов, которые существуют в классе модели.

Указание вложенной сериализации¶

По умолчанию ModelSerializer использует первичные ключи для отношений, но вы также можете легко генерировать вложенные представления, используя опцию depth :

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

Если вы хотите настроить способ сериализации, вам нужно будет определить поле самостоятельно.

Указание полей в явном виде¶

Дополнительные поля могут соответствовать любому свойству или вызываемому объекту модели.

Указание полей, доступных только для чтения¶

Этот параметр должен представлять собой список или кортеж имен полей и объявляется следующим образом:

Примечание: Существует особый случай, когда поле, доступное только для чтения, является частью ограничения unique_together на уровне модели. В этом случае поле требуется классу сериализатора для проверки ограничения, но также не должно редактироваться пользователем.

Дополнительные аргументы ключевых слов¶

Этот параметр представляет собой словарь, отображающий имена полей на словарь аргументов ключевых слов. Например:

Следует помнить, что если поле уже было явно объявлено в классе сериализатора, то опция extra_kwargs будет проигнорирована.

Реляционные поля¶

При сериализации экземпляров модели существует несколько различных способов представления отношений. Представление по умолчанию для ModelSerializer заключается в использовании первичных ключей связанных экземпляров.

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

Настройка сопоставлений полей¶

Класс ModelSerializer также предоставляет API, который вы можете переопределить, чтобы изменить способ автоматического определения полей сериализатора при инстанцировании сериализатора.

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

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

Класс поля сериализатора, который должен использоваться для любого поля url на сериализаторе.

По умолчанию serializers.HyperlinkedIdentityField

Класс поля сериализатора, который должен использоваться для любых полей выбора в сериализаторе.

По умолчанию serializers.ChoiceField

Вызывается для генерации поля сериализатора, которое сопоставляется со стандартным полем модели.

Вызывается для генерации поля сериализатора, которое сопоставляется с полем реляционной модели.

Вызывается для генерации поля сериализатора, которое сопоставляется со свойством или методом с нулевым аргументом класса модели.

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

HyperlinkedModelSerializer¶

По умолчанию сериализатор будет включать поле url вместо поля первичного ключа.

Вы можете явно включить первичный ключ, добавив его, например, к опции fields :

Абсолютные и относительные URL-адреса¶

При инстанцировании HyperlinkedModelSerializer вы должны включить текущий request в контекст сериализатора, например:

Это гарантирует, что гиперссылки могут включать соответствующее имя хоста, так что результирующее представление использует полные URL-адреса, такие как:

Вместо относительных URL-адресов, таких как:

Если вы хотите использовать относительные URL, вы должны явно передать <'request': None>в контексте сериализатора.

Как определяются представления с гиперссылками¶

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

В качестве альтернативы вы можете явно задать поля в сериализаторе. Например:

Изменение имени поля URL¶

ListSerializer¶

Класс ListSerializer обеспечивает поведение для сериализации и валидации нескольких объектов одновременно. Обычно типично не требуется использовать ListSerializer напрямую, вместо этого следует просто передать many=True при инстанцировании сериализатора.

Следующий аргумент также может быть передан полю ListSerializer или сериализатору, которому передается many=True :

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

Вы хотите настроить поведение создания или обновления нескольких объектов.

По умолчанию класс ListSerializer не поддерживает множественные обновления. Это связано с тем, что поведение, которое следует ожидать для вставок и удалений, неоднозначно.

Для поддержки множественных обновлений необходимо сделать это в явном виде. При написании кода множественных обновлений обязательно учитывайте следующее:

Как определить, какой экземпляр должен быть обновлен для каждого элемента в списке данных?

Как следует обрабатывать вставки? Являются ли они недействительными или создают новые объекты?

Как следует обрабатывать удаления? Подразумевают ли они удаление объекта или удаление отношения? Должны ли они молча игнорироваться, или они недействительны?

Как следует обрабатывать упорядочивание? Влечет ли изменение положения двух элементов изменение состояния или оно игнорируется?

Вот пример того, как можно реализовать несколько обновлений:

BaseSerializer¶

BaseSerializer класс, который можно использовать для простой поддержки альтернативных стилей сериализации и десериализации.

Этот класс реализует тот же базовый API, что и класс Serializer :

Есть четыре метода, которые могут быть переопределены, в зависимости от того, какую функциональность вы хотите, чтобы поддерживал класс сериализатора:

Очень просто создать сериализатор только для чтения для преобразования экземпляров HighScore в примитивные типы данных.

Теперь мы можем использовать этот класс для сериализации отдельных экземпляров HighScore :

Или используйте его для сериализации нескольких экземпляров:

Класс BaseSerializer также полезен, если вы хотите реализовать новые общие классы сериализаторов для работы с определенными стилями сериализации или для интеграции с альтернативными бэкендами хранения данных.

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

Расширенное использование сериализатора¶

Переопределение поведения сериализации и десериализации¶

Некоторые причины, по которым это может быть полезно, включают…

Добавление нового поведения для новых базовых классов сериализаторов.

Небольшое изменение поведения существующего класса.

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

Подписи для этих методов следующие:

.to_representation(self, instance) ¶

Принимает экземпляр объекта, который требует сериализации, и должен вернуть примитивное представление. Обычно это означает возврат структуры встроенных в Python типов данных. Точные типы, которые могут быть обработаны, зависят от классов рендеринга, которые вы настроили для своего API.

Может быть переопределена для изменения стиля представления. Например:

.to_internal_value(self, data) ¶

Наследование сериализатора¶

Подобно формам Django, вы можете расширять и повторно использовать сериализаторы с помощью наследования. Это позволяет вам объявить общий набор полей или методов в родительском классе, который затем может быть использован в нескольких сериализаторах. Например,

Обычно мы рекомендуем не использовать наследование для внутренних классов Meta, а вместо этого объявлять все опции явно.

Кроме того, следующие предостережения относятся к наследованию сериализаторов:

Динамическое изменение полей¶

Изменение аргумента fields напрямую позволяет вам делать такие интересные вещи, как изменение аргументов полей сериализатора во время выполнения, а не в момент объявления сериализатора.

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

Это позволит вам сделать следующее:

Настройка полей по умолчанию¶

REST framework 2 предоставил API, позволяющий разработчикам переопределять, как класс ModelSerializer будет автоматически генерировать набор полей по умолчанию.

Поскольку сериализаторы были кардинально переработаны в версии 3.0, этот API больше не существует. Вы все еще можете изменять создаваемые поля, но вам придется обратиться к исходному коду, и имейте в виду, что если изменения, которые вы делаете, направлены против частных частей API, то они могут быть изменены.

Пакеты сторонних производителей¶

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

Django REST marshmallow¶

Серпи¶

MongoengineModelSerializer¶

Пакет django-rest-framework-mongoengine предоставляет класс MongoEngineModelSerializer сериализатора, который поддерживает использование MongoDB в качестве уровня хранения данных для REST-фреймворка Django.

GeoFeatureModelSerializer¶

HStoreSerializer¶

Пакет django-rest-framework-hstore предоставляет HStoreSerializer для поддержки django-hstore DictionaryField модельного поля и его schema-mode возможности.

Динамический REST¶

Пакет dynamic-rest расширяет интерфейсы ModelSerializer и ModelViewSet, добавляя параметры запроса API для фильтрации, сортировки, включения/исключения всех полей и отношений, определенных вашими сериализаторами.

Миксин динамических полей¶

Пакет drf-dynamic-fields предоставляет миксин для динамического ограничения полей сериализатора подмножеством, заданным параметром URL.

DRF FlexFields¶

Пакет drf-flex-fields расширяет ModelSerializer и ModelViewSet для обеспечения широко используемой функциональности для динамической установки полей и расширения примитивных полей во вложенные модели, как из параметров URL, так и из определений класса вашего сериализатора.

Расширения сериализатора¶

Пакет django-rest-framework-serializer-extensions предоставляет набор инструментов для DRY up ваших сериализаторов, позволяя определять поля на основе каждого представления/запроса. Поля могут быть внесены в белый или черный список, а дочерние сериализаторы могут быть дополнительно расширены.

Формы HTML JSON¶

DRF-Base64¶

DRF-Base64 предоставляет набор сериализаторов полей и моделей, который обрабатывает загрузку файлов в base64-кодировке.

QueryFields¶

djangorestframework-queryfields позволяет клиентам API указать, какие поля будут отправлены в ответе с помощью параметров запроса включения/исключения.

DRF Записываемый вложенный¶

Пакет drf-writable-nested предоставляет записываемый сериализатор вложенных моделей, который позволяет создавать/обновлять модели с вложенными связанными данными.

DRF Шифровать содержимое¶

Пакет drf-encrypt-content помогает вам шифровать данные, сериализованные с помощью ModelSerializer. Он также содержит некоторые вспомогательные функции. Которые помогут вам зашифровать ваши данные.

Источник