REST-фреймворк Django 3.2¶
Релиз 3.2 - это первая версия, включающая интерфейс администратора для просматриваемого API.
Этот интерфейс предназначен для более удобного взаимодействия с API. Он может быть использован как замена существующему BrowsableAPIRenderer , так и вместе с ним, позволяя переключаться между двумя стилями по мере необходимости.
Мы также исправили огромное количество проблем, провели многочисленные чистки и улучшения.
За время работы над серией 3.1.x мы resolved nearly 600 tickets на нашем трекере проблем на GitHub. Это означает, что в настоящее время мы закрываем около 100 проблем или запросов на доработку в месяц.
Все это было бы невозможно без поддержки наших замечательных сторонников на Kickstarter. Если вы ищете работу в области разработки Django, мы настоятельно рекомендуем пройти по ссылке a look through our sponsors и узнать, кто нанимается на работу.
AdminRenderer¶
Чтобы включить AdminRenderer, просто добавьте его в настройки:
REST_FRAMEWORK = {
'DEFAULT_RENDERER_CLASSES': [
'rest_framework.renderers.JSONRenderer',
'rest_framework.renderers.AdminRenderer',
'rest_framework.renderers.BrowsableAPIRenderer'
],
'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
'PAGE_SIZE': 100
}
Есть некоторые ограничения в AdminRenderer , в частности, он пока не может обрабатывать списки или словари, так как у нас нет полей HTML формы, которые бы их поддерживали.
Также обратите внимание, что это начальный выпуск, и у нас еще нет публичного API для изменения поведения или документации по переопределению шаблонов.
Идея заключается в том, чтобы выпустить его для пользователей как можно раньше, чтобы мы могли получить отзывы и выпустить более полнофункциональную версию в версии 3.3.
Поддерживаемые версии¶
В этом выпуске прекращена поддержка Django 1.4.
Поддерживаемые нами версии Django теперь 1.5.6+, 1.6.3+, 1.7 и 1.8.
Амортизация¶
В версии 3.2 нет новых ухудшений, хотя ряд существующих ухудшений теперь обострился в соответствии с нашей политикой ухудшений.
request.DATAбыл переведен на путь устаревания в версии 3.0. Теперь он удален, и его использование приведет к ошибке. Вместо него используйте более питонический стильrequest.data.request.QUERY_PARAMSбыл переведен на путь устаревания в версии 3.0. Теперь он удален, и его использование приведет к ошибке. Вместо него используйте более питонический стильrequest.query_params.Следующие опции
ModelSerializer.Metaтеперь удалены:write_only_fields,view_name,lookup_field. Вместо них используйте более общую опциюextra_kwargs.
Следующие атрибуты и настройки представления пагинации были перенесены в атрибуты класса пагинации с версии 3.1. Их использование ранее находилось в категории «ожидающие устаревания», а теперь перешло в категорию «устаревшие». Они будут продолжать функционировать, но будут вызывать ошибки.
view.paginate_by- Вместо этого используйтеpaginator.page_size.view.page_query_param- Вместо этого используйтеpaginator.page_query_param.view.paginate_by_param- Вместо этого используйтеpaginator.page_size_query_param.view.max_paginate_by- Вместо этого используйтеpaginator.max_page_size.settings.PAGINATE_BY- Вместо этого используйтеpaginator.page_size.settings.PAGINATE_BY_PARAM- Вместо этого используйтеpaginator.page_size_query_param.settings.MAX_PAGINATE_BY- Вместо этого используйтеpaginator.max_page_size.
Модификации поведения в списке¶
Есть несколько исправлений, которые стоит отметить, поскольку они вносят отличия в поведение.
Они немного тонкие и, вероятно, не повлияют на большинство пользователей, но их стоит понять, прежде чем обновлять свой проект.
Поля ManyToMany и blank=True¶
Теперь мы добавили аргумент allow_empty, который можно использовать с ListSerializer , или с many=True отношениями. По умолчанию он равен True, но может быть установлен в False, если вы хотите запретить использование пустых списков в качестве допустимого ввода.
В дополнение к этому мы теперь можем правильно отразить поведение Django ModelForm в отношении того, как проверяются поля «многие ко многим».
Ранее поле «многие ко многим» в модели отображалось на поле сериализатора, которое допускало ввод пустого или непустого списка. Теперь поле «многие ко многим» будет отображаться на поле сериализатора, которое требует как минимум одного входа, если только в поле модели не установлено значение blank=True.
Вот как выглядит отображение на практике:
models.ManyToManyField()→serializers.PrimaryKeyRelatedField(many=True, allow_empty=False)models.ManyToManyField(blank=True)→serializers.PrimaryKeyRelatedField(many=True)
Итог таков: Если в ваших моделях много-много полей, то убедитесь, что вы включили аргумент blank=True, если вы хотите разрешить пустые вводы в эквивалентные поля ModelSerializer.
Поля списка и allow_null¶
При использовании allow_null с ListField или вложенным сериализатором many=True предыдущее поведение заключалось в разрешении значений null в качестве элементов списка. Теперь вместо списка будет разрешено null значений.
Например, возьмем следующее поле:
NestedSerializer(many=True, allow_null=True)
Ранее поведение при проверке было следующим:
[{…}, null, {…}]является действительным.nullявляется недействительным.
Начиная с версии 3.2.0 наше поведение при проверке выглядит следующим образом:
[{…}, null, {…}]является недействительным.nullявляется действительным.
Если вы хотите разрешить null дочерних элементов, вам нужно вместо этого указать allow_null на дочерний класс, используя явное ListField вместо many=True. Например:
ListField(child=NestedSerializer(allow_null=True))
Что дальше?¶
Выпуск 3.3 в настоящее время запланирован на начало октября, и это будет последний выпуск, финансируемый на Kickstarter.
В этот выпуск планируется включить:
Элементы управления поиском и фильтрацией в просматриваемом API и интерфейсе администратора.
Улучшения и публичный API для интерфейса администратора.
Улучшения и публичный API для наших шаблонизированных HTML форм и полей.
Поддержка вложенных объектов и списков в HTML-формах.
Еще раз спасибо всем нашим спонсорам и сторонникам.