.данные¶

request.data возвращает разобранное содержимое тела запроса. Это похоже на стандартные атрибуты request.POST и request.FILES, за исключением того, что:

• Он включает в себя все разобранное содержимое, включая файловые и нефайловые входы.

• Он поддерживает разбор содержимого методов HTTP, отличных от POST , что означает, что вы можете получить доступ к содержимому запросов PUT и PATCH.

• Он поддерживает гибкий разбор запросов фреймворка REST, а не просто поддерживает данные формы. Например, вы можете обрабатывать входящие JSON data аналогично тому, как вы обрабатываете входящие form data.

Более подробную информацию см. в parsers documentation.

.query_params¶

request.query_params - это более правильно названный синоним request.GET.

Для ясности внутри вашего кода мы рекомендуем использовать request.query_params вместо стандартного для Django request.GET. Это поможет сохранить вашу кодовую базу более корректной и очевидной - любой тип HTTP метода может включать параметры запроса, а не только GET запросы.

.парсеры¶

Класс APIView или декоратор @api_view обеспечат автоматическую установку этого свойства в список Parser экземпляров на основе parser_classes, установленного на представлении, или на основе DEFAULT_PARSER_CLASSES настройки.

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

Примечание: Если клиент отправляет некачественное содержимое, то обращение к request.data может вызвать ошибку ParseError. По умолчанию класс APIView или декоратор @api_view REST framework поймает ошибку и вернет ответ 400 Bad Request.

Если клиент отправляет запрос с типом содержимого, который не может быть разобран, то будет вызвано исключение UnsupportedMediaType, которое по умолчанию будет поймано и вернет ответ 415 Unsupported Media Type.

.accepted_renderer¶

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

.accepted_media_type¶

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

.пользователь¶

request.user обычно возвращает экземпляр django.contrib.auth.models.User , хотя поведение зависит от используемой политики аутентификации.

Если запрос не аутентифицирован, значение по умолчанию request.user является экземпляром django.contrib.auth.models.AnonymousUser.

Более подробную информацию см. в authentication documentation.

.auth¶

request.auth возвращает любой дополнительный контекст аутентификации. Точное поведение request.auth зависит от используемой политики аутентификации, но обычно это может быть экземпляр маркера, по которому был аутентифицирован запрос.

Если запрос не аутентифицирован, или если отсутствует дополнительный контекст, значение по умолчанию request.auth равно None.

Более подробную информацию см. в authentication documentation.

.аутентификаторы¶

Класс APIView или декоратор @api_view обеспечат автоматическую установку этого свойства в список Authentication экземпляров на основе authentication_classes, установленного на представлении, или на основе DEFAULT_AUTHENTICATORS настройки.

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

Примечание: При вызове свойств WrappedAttributeError или .user может возникнуть ошибка .auth. Эти ошибки исходят от аутентификатора как стандартное AttributeError , однако необходимо, чтобы они были повторно вызваны как исключение другого типа, чтобы предотвратить их подавление внешним доступом к свойству. Python не распознает, что AttributeError исходит от аутентификатора, и вместо этого будет считать, что объект запроса не имеет .user или .auth свойства. Аутентификатор необходимо будет исправить.

.метод¶

request.method возвращает uppercased строковое представление HTTP-метода запроса.

Браузерные формы PUT , PATCH и DELETE поддерживаются прозрачно.

Для получения дополнительной информации см. раздел browser enhancements documentation.

.content_type¶

request.content_type , возвращает строковый объект, представляющий тип медиа тела HTTP запроса, или пустую строку, если тип медиа не был предоставлен.

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

Если вам необходимо получить доступ к типу содержимого запроса, вам следует использовать свойство .content_type, а не request.META.get('HTTP_CONTENT_TYPE') , так как оно обеспечивает прозрачную поддержку неформенного содержимого в браузере.

Для получения дополнительной информации см. раздел browser enhancements documentation.

.поток¶

request.stream возвращает поток, представляющий содержимое тела запроса.

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