Serializer 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() возвращает аргументы, которые вы передадите сериализатору при создании его экземпляра.

Источник

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 по проводам, но сериализатор может работать с любым форматом (текстовым или нет).

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

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

django.core.serializers. get_serializer ( format )¶

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

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

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

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

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

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

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

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

Десериализация данных также является довольно простой операцией:

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

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

Это гарантирует, что десериализация является неразрушающей операцией, даже если данные в вашем сериализованном представлении не совпадают с данными в базе данных. Обычно работа с этими экземплярами 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() :

DjangoJSONEncoder ¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Сериализация объектов 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 было сериализовать.

Источник

Serializers

Expanding the usefulness of the serializers is something that we would like to address. However, it’s not a trivial problem, and it will take some serious design work.

The serializers in REST framework work very similarly to Django’s Form and ModelForm classes. We provide a Serializer class which gives you a powerful, generic way to control the output of your responses, as well as a ModelSerializer class which provides a useful shortcut for creating serializers that deal with model instances and querysets.

Declaring Serializers

Let’s start by creating a simple object we can use for example purposes:

We’ll declare a serializer that we can use to serialize and deserialize data that corresponds to Comment objects.

Declaring a serializer looks very similar to declaring a form:

Serializing objects

We can now use CommentSerializer to serialize a comment, or list of comments. Again, using the Serializer class looks a lot like using a Form class.

Deserializing objects

Deserialization is similar. First we parse a stream into Python native datatypes.

. then we restore those native datatypes into a dictionary of validated data.

Saving instances

If your object instances correspond to Django models you’ll also want to ensure that these methods save the object to the database. For example, if Comment was a Django model, the methods might look like this:

Sometimes you’ll want your view code to be able to inject additional data at the point of saving the instance. This additional data might include information like the current user, the current time, or anything else that is not part of the request data.

Validation

Each key in the dictionary will be the field name, and the values will be lists of strings of any error messages corresponding to that field. The non_field_errors key may also be present, and will list any general validation errors. The name of the non_field_errors key may be customized using the NON_FIELD_ERRORS_KEY REST framework setting.

When deserializing a list of items, errors will be returned as a list of dictionaries representing each of the deserialized items.

Raising an exception on invalid data

These exceptions are automatically dealt with by the default exception handler that REST framework provides, and will return HTTP 400 Bad Request responses by default.

Field-level validation

These methods take a single argument, which is the field value that requires validation.

Note: If your is declared on your serializer with the parameter required=False then this validation step will not take place if the field is not included.

Object-level validation

Validators

Individual fields on a serializer can include validators, by declaring them on the field instance, for example:

Serializer classes can also include reusable validators that are applied to the complete set of field data. These validators are included by declaring them on an inner Meta class, like so:

For more information see the validators documentation.

Accessing the initial data and instance

Partial updates

By default, serializers must be passed values for all required fields or they will raise validation errors. You can use the partial argument in order to allow partial updates.

Dealing with nested objects

The previous examples are fine for dealing with objects that only have simple datatypes, but sometimes we also need to be able to represent more complex objects, where some of the attributes of an object might not be simple datatypes such as strings, dates or integers.

If a nested representation may optionally accept the None value you should pass the required=False flag to the nested serializer.

Similarly if a nested representation should be a list of items, you should pass the many=True flag to the nested serializer.

Writable nested representations

When dealing with nested representations that support deserializing the data, any errors with nested objects will be nested under the field name of the nested object.

The following example demonstrates how you might handle creating a user with a nested profile object.

There are however, third-party packages available such as DRF Writable Nested that support automatic writable nested representations.

Handling saving related instances in model manager classes

An alternative to saving multiple related instances in the serializer is to write custom model manager classes that handle creating the correct instances.

For example, suppose we wanted to ensure that User instances and Profile instances are always created together as a pair. We might write a custom manager class that looks something like this:

For more details on this approach see the Django documentation on model managers, and this blogpost on using model and manager classes.

Dealing with multiple objects

The Serializer class can also handle serializing or deserializing lists of objects.

Serializing multiple objects

To serialize a queryset or list of objects instead of a single object instance, you should pass the many=True flag when instantiating the serializer. You can then pass a queryset or list of objects to be serialized.

Deserializing multiple objects

The default behavior for deserializing multiple objects is to support multiple object creation, but not support multiple object updates. For more information on how to support or customize either of these cases, see the ListSerializer documentation below.

Including extra context

There are some cases where you need to provide extra context to the serializer in addition to the object being serialized. One common case is if you’re using a serializer that includes hyperlinked relations, which requires the serializer to have access to the current request so that it can properly generate fully qualified URLs.

You can provide arbitrary additional context by passing a context argument when instantiating the serializer. For example:

ModelSerializer

Often you’ll want serializer classes that map closely to Django model definitions.

The ModelSerializer class provides a shortcut that lets you automatically create a Serializer class with fields that correspond to the Model fields.

The ModelSerializer class is the same as a regular Serializer class, except that:

Declaring a ModelSerializer looks like this:

By default, all the model fields on the class will be mapped to a corresponding serializer fields.

Inspecting a ModelSerializer

Serializer classes generate helpful verbose representation strings, that allow you to fully inspect the state of their fields. This is particularly useful when working with ModelSerializers where you want to determine what set of fields and validators are being automatically created for you.

Specifying which fields to include

You can also set the fields attribute to the special value ‘__all__’ to indicate that all fields in the model should be used.

You can set the exclude attribute to a list of fields to be excluded from the serializer.

The names in the fields and exclude attributes will normally map to model fields on the model class.

Alternatively names in the fields options can map to properties or methods which take no arguments that exist on the model class.

Specifying nested serialization

The default ModelSerializer uses primary keys for relationships, but you can also easily generate nested representations using the depth option:

The depth option should be set to an integer value that indicates the depth of relationships that should be traversed before reverting to a flat representation.

If you want to customize the way the serialization is done you’ll need to define the field yourself.

Specifying fields explicitly

You can add extra fields to a ModelSerializer or override the default fields by declaring fields on the class, just as you would for a Serializer class.

Extra fields can correspond to any property or callable on the model.

Specifying read only fields

This option should be a list or tuple of field names, and is declared as follows:

Model fields which have editable=False set, and AutoField fields will be set to read-only by default, and do not need to be added to the read_only_fields option.

Note: There is a special-case where a read-only field is part of a unique_together constraint at the model level. In this case the field is required by the serializer class in order to validate the constraint, but should also not be editable by the user.

The right way to deal with this is to specify the field explicitly on the serializer, providing both the read_only=True and default=… keyword arguments.

One example of this is a read-only relation to the currently authenticated User which is unique_together with another identifier. In this case you would declare the user field like so:

Additional keyword arguments

This option is a dictionary, mapping field names to a dictionary of keyword arguments. For example:

Please keep in mind that, if the field has already been explicitly declared on the serializer class, then the extra_kwargs option will be ignored.

Relational fields

When serializing model instances, there are a number of different ways you might choose to represent relationships. The default representation for ModelSerializer is to use the primary keys of the related instances.

Alternative representations include serializing using hyperlinks, serializing complete nested representations, or serializing with a custom representation.

For full details see the serializer relations documentation.

Customizing field mappings

The ModelSerializer class also exposes an API that you can override in order to alter how serializer fields are automatically determined when instantiating the serializer.

Normally if a ModelSerializer does not generate the fields you need by default then you should either add them to the class explicitly, or simply use a regular Serializer class instead. However in some cases you may want to create a new base class that defines how the serializer fields are created for any given model.

A mapping of Django model fields to REST framework serializer fields. You can override this mapping to alter the default serializer fields that should be used for each model field.

This property should be the serializer field class, that is used for relational fields by default.

The serializer field class that should be used for any url field on the serializer.

Defaults to serializers.HyperlinkedIdentityField

The serializer field class that should be used for any choice fields on the serializer.

Defaults to serializers.ChoiceField

The field_class and field_kwargs API

Called to generate a serializer field that maps to a standard model field.

The default implementation returns a serializer class based on the serializer_field_mapping attribute.

Called to generate a serializer field that maps to a relational model field.

The default implementation returns a serializer class based on the serializer_related_field attribute.

Called to generate a serializer field that maps to a relational model field, when the depth option has been set.

The nested_depth will be the value of the depth option, minus one.

Called to generate a serializer field that maps to a property or zero-argument method on the model class.

The default implementation returns a ReadOnlyField class.

Called to generate a serializer field for the serializer’s own url field. The default implementation returns a HyperlinkedIdentityField class.

Called when the field name did not map to any model field or model property. The default implementation raises an error, although subclasses may customize this behavior.

HyperlinkedModelSerializer

The HyperlinkedModelSerializer class is similar to the ModelSerializer class except that it uses hyperlinks to represent relationships, rather than primary keys.

By default the serializer will include a url field instead of a primary key field.

The url field will be represented using a HyperlinkedIdentityField serializer field, and any relationships on the model will be represented using a HyperlinkedRelatedField serializer field.

You can explicitly include the primary key by adding it to the fields option, for example:

Absolute and relative URLs

When instantiating a HyperlinkedModelSerializer you must include the current request in the serializer context, for example:

Doing so will ensure that the hyperlinks can include an appropriate hostname, so that the resulting representation uses fully qualified URLs, such as:

Rather than relative URLs, such as:

If you do want to use relative URLs, you should explicitly pass <'request': None>in the serializer context.

How hyperlinked views are determined

There needs to be a way of determining which views should be used for hyperlinking to model instances.

You can override a URL field view name and lookup field by using either, or both of, the view_name and lookup_field options in the extra_kwargs setting, like so:

Alternatively you can set the fields on the serializer explicitly. For example:

Tip: Properly matching together hyperlinked representations and your URL conf can sometimes be a bit fiddly. Printing the repr of a HyperlinkedModelSerializer instance is a particularly useful way to inspect exactly which view names and lookup fields the relationships are expected to map too.

Changing the URL field name

The name of the URL field defaults to ‘url’. You can override this globally, by using the URL_FIELD_NAME setting.

ListSerializer

The ListSerializer class provides the behavior for serializing and validating multiple objects at once. You won’t typically need to use ListSerializer directly, but should instead simply pass many=True when instantiating a serializer.

When a serializer is instantiated and many=True is passed, a ListSerializer instance will be created. The serializer class then becomes a child of the parent ListSerializer

The following argument can also be passed to a ListSerializer field or a serializer that is passed many=True :

allow_empty

This is True by default, but can be set to False if you want to disallow empty lists as valid input.

Customizing ListSerializer behavior

There are a few use cases when you might want to customize the ListSerializer behavior. For example:

For these cases you can modify the class that is used when many=True is passed, by using the list_serializer_class option on the serializer Meta class.

Customizing multiple create

Customizing multiple update

By default the ListSerializer class does not support multiple updates. This is because the behavior that should be expected for insertions and deletions is ambiguous.

To support multiple updates you’ll need to do so explicitly. When writing your multiple update code make sure to keep the following in mind:

Here’s an example of how you might choose to implement multiple updates:

It is possible that a third party package may be included alongside the 3.1 release that provides some automatic support for multiple update operations, similar to the allow_add_remove behavior that was present in REST framework 2.

Customizing ListSerializer initialization

Occasionally you might need to explicitly specify how the child and parent classes should be instantiated when many=True is passed. You can do so by using the many_init class method.

BaseSerializer

BaseSerializer class that can be used to easily support alternative serialization and deserialization styles.

This class implements the same basic API as the Serializer class:

There are four methods that can be overridden, depending on what functionality you want the serializer class to support:

The only difference you’ll notice when doing so is the BaseSerializer classes will not generate HTML forms in the browsable API. This is because the data they return does not include all the field information that would allow each field to be rendered into a suitable HTML input.

Read-only BaseSerializer classes

It’s simple to create a read-only serializer for converting HighScore instances into primitive data types.

We can now use this class to serialize single HighScore instances:

Or use it to serialize multiple instances:

Read-write BaseSerializer classes

Creating new base classes

The BaseSerializer class is also useful if you want to implement new generic serializer classes for dealing with particular serialization styles, or for integrating with alternative storage backends.

The following class is an example of a generic serializer that can handle coercing arbitrary objects into primitive representations.

Advanced serializer usage

Overriding serialization and deserialization behavior

Some reasons this might be useful include.

The signatures for these methods are as follows:

Takes the object instance that requires serialization, and should return a primitive representation. Typically this means returning a structure of built-in Python datatypes. The exact types that can be handled will depend on the render classes you have configured for your API.

May be overridden in order to modify the representation style. For example:

Serializer Inheritance

Similar to Django forms, you can extend and reuse serializers through inheritance. This allows you to declare a common set of fields or methods on a parent class that can then be used in a number of serializers. For example,

Like Django’s Model and ModelForm classes, the inner Meta class on serializers does not implicitly inherit from it’s parents’ inner Meta classes. If you want the Meta class to inherit from a parent class you must do so explicitly. For example:

Typically we would recommend not using inheritance on inner Meta classes, but instead declaring all options explicitly.

Additionally, the following caveats apply to serializer inheritance:

It’s possible to declaratively remove a Field inherited from a parent class by setting the name to be None on the subclass.

However, you can only use this technique to opt out from a field defined declaratively by a parent class; it won’t prevent the ModelSerializer from generating a default field. To opt-out from default fields, see Specifying which fields to include.

Dynamically modifying fields

Modifying the fields argument directly allows you to do interesting things such as changing the arguments on serializer fields at runtime, rather than at the point of declaring the serializer.

Example

For example, if you wanted to be able to set which fields should be used by a serializer at the point of initializing it, you could create a serializer class like so:

This would then allow you to do the following:

Customizing the default fields

REST framework 2 provided an API to allow developers to override how a ModelSerializer class would automatically generate the default set of fields.

Because the serializers have been fundamentally redesigned with 3.0 this API no longer exists. You can still modify the fields that get created but you’ll need to refer to the source code, and be aware that if the changes you make are against private bits of API then they may be subject to change.

Third party packages

The following third party packages are also available.

Django REST marshmallow

The django-rest-marshmallow package provides an alternative implementation for serializers, using the python marshmallow library. It exposes the same API as the REST framework serializers, and can be used as a drop-in replacement in some use-cases.

Serpy

The serpy package is an alternative implementation for serializers that is built for speed. Serpy serializes complex datatypes to simple native types. The native types can be easily converted to JSON or any other format needed.

MongoengineModelSerializer

The django-rest-framework-mongoengine package provides a MongoEngineModelSerializer serializer class that supports using MongoDB as the storage layer for Django REST framework.

GeoFeatureModelSerializer

The django-rest-framework-gis package provides a GeoFeatureModelSerializer serializer class that supports GeoJSON both for read and write operations.

HStoreSerializer

The django-rest-framework-hstore package provides an HStoreSerializer to support django-hstore DictionaryField model field and its schema-mode feature.

Dynamic REST

The dynamic-rest package extends the ModelSerializer and ModelViewSet interfaces, adding API query parameters for filtering, sorting, and including / excluding all fields and relationships defined by your serializers.

Dynamic Fields Mixin

The drf-dynamic-fields package provides a mixin to dynamically limit the fields per serializer to a subset specified by an URL parameter.

DRF FlexFields

The drf-flex-fields package extends the ModelSerializer and ModelViewSet to provide commonly used functionality for dynamically setting fields and expanding primitive fields to nested models, both from URL parameters and your serializer class definitions.

Serializer Extensions

The django-rest-framework-serializer-extensions package provides a collection of tools to DRY up your serializers, by allowing fields to be defined on a per-view/request basis. Fields can be whitelisted, blacklisted and child serializers can be optionally expanded.

HTML JSON Forms

DRF-Base64

DRF-Base64 provides a set of field and model serializers that handles the upload of base64-encoded files.

QueryFields

djangorestframework-queryfields allows API clients to specify which fields will be sent in the response via inclusion/exclusion query parameters.

DRF Writable Nested

The drf-writable-nested package provides writable nested model serializer which allows to create/update models with nested related data.

DRF Encrypt Content

The drf-encrypt-content package helps you encrypt your data, serialized through ModelSerializer. It also contains some helper functions. Which helps you to encrypt your data.

Источник