Общие представления (generic views) были придуманы для часто повторяющихся действиий... Они используют общие элементы, встречающиеся в представлении, и сокращают их, так, что вы быстро можете написать самые распространенные представления, при этом не повторяясь.— Документация Django
APIView
или повторно использовать миксины и базовые классы, используемые в общих представлениях для того, чтобы создать свой набор многократно используемых общих представлений..as_view()
. Например, ваш URLconf может включать следующую строку:APIView
, реализуя часто повторяющееся поведение. Каждое общее представление строится путем комбинации GenericAPIView
с одним из классов-миксинов.queryset
- queryset, который должен использоваться для того, чтобы возвращать объекты представления. Как правило, вы должны либо прописать этот атбрибут, либо переписать метод get_queryset()
. Если вы переписываете метод представления, важно, чтобы вы обращались к get_queryset()
вместо того, чтобы напрямую получать доступ к этому свойству, так как queryset вычисляется лишь единожды, и эти результаты будут кешированы для всех последующих запросов.serializer_class
- класс сериализатора, который должен использоваться для валидации, десериализации ввода и для сериализации вывода. Как правило, вы должны либо прописать этот атрибут, либо переписать метод get_serializer_class()
.lookup_field
- поле модели, которое используется для поиска объектов отдельных экземпляров модели. По умолчанию стоит pk
. Обратите внимание, что при использовании API по ссылке, вам нужно удостовериться, что в представленит API и в классах сериализатора прописаны поля подстановки, если вам нужно использовать индивидуальное значение.lookup_url_kwarg
- ключовй аргумент URL, который используется для поиска объекта. URL conf должен включать аргумент-ключ, который относится к этому значению. По умолчнию указаны те же значения, что и в lookup_field
.pagination_class
- класс пагинации, который нужно использовать при постраничном выводе результатов list. По умолчанию принимает те же значения, что и настройка DEFAULT_PAGINATION_CLASS
, а именно 'rest_framework.pagination.PageNumberPagination'
. Настройка pagination_class=None
отключает пагианцию в данном представлении.filter_backends
- список классов, используемых для фильтрации queryset. По умолчанию принимает такие же значения, как и настройка DEFAULT_FILTER_BACKENDS
.get_queryset(self)
self.queryset
, так как self.queryset
вычисляется тольно один раз, и эти результаты кешируются для все последующих запросов.get_object(self)
lookup_field
. Вместо этого может использоваться более сложный сценарий, например поиск объектов по более чем одному URL kwarg.self.check_object_permissions
и просто вернуть объект из get_object_or_404
.filter_queryset(self, queryset)
get_serializer_class(self)
serializer_class
.perform_create(self, serializer)
- Вызывает CreateModelMixin
при сохранении нового экземпляра объекта.perform_update(self, serializer)
- Вызывает UpdateModelMixin
при сохранении существующего экземпляра объекта.perform_destroy(self, instance)
- Вызывает DestroyModelMixin
при удалении экземпляра объекта.ValidationError()
. Это может пригодиться, если вы хотите применить некую логику к валидации на этапе сохранения в базу данных. Например:pre_save
, post_save
, pre_delete
и post_delete
, которые больше недоступны.GenericAPIView
.get_serializer_context(self)
- возвращает словарь с любым дополнительным контекстом, который должен быть предоставлен сериализатору. По умолчанию включает ключи'request', 'view' и 'format'.get_serializer(self, instance=None, data=None, many=False, partial=False)
- Возвращает сериализованный экземпляр.get_paginated_response(self, data)
- Постранично выводит объект Response
.paginate_queryset(self, queryset)
- Постранично выводит queryset, либо возвращает объект страницы, либо None
, если пагинация не настроена для данного представления.filter_queryset(self, queryset)
- При наличии queryset фильтруего его с помощью фильтров бэкэнда, возвращая новый queryset.get()
и .post()
. Это позволяет более гибко настроить поведение.rest_framework.mixins
..list(request, *args, **kwargs)
, который внедряет листинг и queryset.200 OK
с сериализованным представлением queryset тела ответа. Опционально данные ответа могуть быть пронумерованны..create(request, *args, **kwargs)
, который реализует создание и сохранение новых экземпляров модели.201 Created
с сериализированным представлением объекта тела запроса. Если представление содержит url-ключ, то Location header ответа будет заполнен этим значением.400 Bad Request
..retrieve(request, *args, **kwargs)
, который реализует возвращение существующего экземпляра модели в ответе.200 OK
с сериализованным представлением queryset тела ответа. В провтинов случае получим 404 Not Found
..update(request, *args, **kwargs
), который реализует дополнение и сохранение существующего экземпляра модели..partial_update(request, *args, **kwargs)
, который похож на метод update
, за исключением того, что все поля update будут опциональными. Это позволяет поддерживать HTTP запросы PATCH
.200 OK
с сериализованным представлением queryset тела ответа.400 Bad Request
..destroy(request, *args, **kwargs)
который реализует удаление текующего экземпляра модели.204 No Content
, в противном случае получим 404 Not Found
.rest_framework.generics
.post
.get
.get
.delete
.put
и patch
.get
и post
.get
, put
и patch
.get
и delete
.get
, put
, patch
и delete
.PUT
только для операций update или create, в зависимости от того существует объект или нет.PUT
для создания является проблематичной задачей, так как это обязательно раскроет информацию о существовании или отсутствии объектов. Также не совсем очевидно преимущество прозрачного воссоздания удаленных экземпляров перед обычным возвратом соообщений 404
. It's also not obvious that transparently allowing re-creating of previously deleted instances is necessarily a better default behavior than simply returning 404 responses.
AllowPUTAsCreateMixin
в ваши представления.django-rest-framework-bulk
задействует миксины общих представлений, а также некоторые распространенные конкретные представления, которые позволяют применять массивные операции через запросы API.Django Rest Multiple Models
предоставлет общее представление (и миксин) для передачи нескольких сериализованных моделей и/или querysets через один API запрос.