Serializers django что это

Как использовать сериализаторы в веб-платформе Django Python

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

Теперь представьте, что вы хотите сохранить и получить данные о заказе из базы данных «ключ-значение». К счастью, его интерфейс принимает и возвращает словари, поэтому вам нужно преобразовать свой объект в словарь:

И если вы хотите получить некоторые данные из этой базы данных, вы можете получить данные dict и превратить их в свой объект Order:

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

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

Django поставляется с модулем сериализации, который позволяет «переводить» модели в другие форматы:

Он охватывает наиболее часто используемые случаи для веб-приложений, таких как JSON, YAML и XML. Но вы также можете использовать сторонние сериализаторы или создать свои собственные. Вам просто нужно зарегистрировать его в своем файле settings.py:

Теперь вы можете сериализовать свой запрос в новый формат:

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

В сообществе Django фреймворк Django REST (DRF) предлагает самые известные сериализаторы. Хотя вы можете использовать сериализаторы Django для создания JSON, на который вы будете отвечать в своем API, один из фреймворка REST имеет приятные функции, которые помогут вам справиться и легко проверить сложные данные.

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

И легко сериализуйте его данные:

После этого вы можете создавать или обновлять экземпляры, вызывая is_valid() для проверки данных и save() для создания или обновления экземпляра:

Сериализаторы моделей

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

Вы можете создать для него сериализатор следующим образом:

Использование сериализаторов в представлениях на основе классов (CBV)

Как и формы с CBV от Django, сериализаторы хорошо интегрируются с DRF. Вы можете установить атрибут serializer_class так, чтобы сериализатор был доступен для представления:

Вы также можете определить метод get_serializer_class() :

В CBV есть и другие методы, которые взаимодействуют с сериализаторами. Например, get_serializer() возвращает уже созданный сериализатор, а get_serializer_context() возвращает аргументы, которые вы передадите сериализатору при создании его экземпляра.

Источник

Эффективное использование DRF-сериализаторов в Django

Для чтения данной статьи потребуются базовые знания по Django REST фреймворку.

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

Мы обсудим следующие вопросы:

Как использовать ключевой аргумент source

Давайте напишем сериализатор, способный создавать серийные представления класса User :

Теперь давайте произведем эту сериализацию:

Чтобы добиться этого, мы можем добавить в код метод CharField с ключевым аргументом source :

Теперь перезапустим оболочку и получим сериализованное представление класса User :

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

Давайте перезапустим оболочку и посмотрим на результат:

Подобно тому как аргумент source работает с методами самого объекта, он также легко взаимодействует и с методами связанных объектов.

Опять сериализуем класс User и получим:

Теперь давайте посмотрим, как легко работает аргумент source с отношением многие-ко-многим ( ManyToManyField ).

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

Выглядеть он будет следующим образом:

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

Как и когда использовать метод SerializerMethodField

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

Вот несколько примеров:

Рассмотрим первый сценарий. Мы хотим изменить значение поля first_name в регистр заголовка (написание с заглавной буквы) в процессе сериализации.

Перезапустим оболочку и произведем сериализацию:

Обратите внимание, что имя (значение поля first_name ) теперь пишется с заглавной буквы.

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

Опять произведем сериализацию и увидим:

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

Как и когда использовать метод to_representation

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

Тогда наш сериализатор будет иметь следующий вид:

Давайте проведем сериализацию для суперюзера.

А теперь отметим пользователя как не-суперюзера и сделаем тоже самое:

Обратите внимание, что ключ admin отсутствует в сериализованных данных для не-суперюзера.

Выводы

Мы рассмотрели поведение сериализатора 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 происходит сериализация данных из БД. Если у вас остались вопросы, задавайте их в комментариях — разберёмся вместе.

Источник

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

‒ 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. Он также содержит некоторые вспомогательные функции. Которые помогут вам зашифровать ваши данные.

Источник