Если вы занимаетесь веб-сервисами на основе REST... вам следует игнорировать request.POST.
- Malcom Tredinnick, Django developers group
Класс Request DRF расширяет стандартный HttpRequest, добавляя поддержку гибкого разбора запросов DRF и аутентификации запросов.
Объекты Request DRF обеспечивают гибкий разбор запросов, что позволяет обрабатывать запросы с данными JSON или другими типами медиа таким же образом, как вы обычно обрабатываете данные формы.
request.data возвращает разобранное содержимое тела запроса. Это похоже на стандартные атрибуты request.POST и request.FILES, за исключением того, что:
- Он включает в себя все разобранное содержимое, включая файловые и нефайловые входы.
- Поддерживается разбор содержимого методов HTTP, отличных от
POST, что означает, что вы можете получить доступ к содержимому запросовPUTиPATCH. - Поддерживается гибкий разбор запросов DRF, а не только поддержка данных формы. Например, вы можете обрабатывать входящие JSON-данные аналогично тому, как вы обрабатываете входящие данные формы.
Более подробную информацию можно найти в документации по парсерам.
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 DRF поймает ошибку и вернет ответ 400 Bad Request.
Если клиент посылает запрос с типом содержимого, который не может быть разобран, то возникает исключение UnsupportedMediaType, которое по умолчанию будет поймано и вернет ответ 415 Unsupported Media Type.
Запрос раскрывает некоторые свойства, которые позволяют определить результат этапа согласования содержимого. Это позволяет вам реализовать такое поведение, как выбор различных схем сериализации для различных типов носителей.
Экземпляр рендерера, который был выбран на этапе согласования содержимого.
Строка, представляющая тип носителя, который был принят на этапе согласования содержимого.
DRF обеспечивает гибкую аутентификацию по каждому запросу, что дает вам возможность:
- Используйте различные политики аутентификации для разных частей вашего API.
- Поддерживайте использование нескольких политик аутентификации.
- Предоставлять информацию о пользователе и маркере, связанную с входящим запросом.
request.user обычно возвращает экземпляр django.contrib.auth.models.User, хотя поведение зависит от используемой политики аутентификации.
Если запрос не аутентифицирован, значением по умолчанию для request.user будет экземпляр django.contrib.auth.models.AnonymousUser.
Более подробную информацию можно найти в документации по аутентификации.
request.auth возвращает любой дополнительный контекст аутентификации. Точное поведение request.auth зависит от используемой политики аутентификации, но обычно это может быть экземпляр токена, по которому был аутентифицирован запрос.
Если запрос не аутентифицирован, или если отсутствует дополнительный контекст, значение по умолчанию request.auth равно None.
Более подробную информацию можно найти в документации по аутентификации.
Класс APIView или декоратор @api_view обеспечат автоматическую установку этого свойства в список экземпляров Authentication на основе authentication_classes, установленных для представления, или на основе параметра DEFAULT_AUTHENTICATORS.
Обычно вам не требуется доступ к этой собственности.
Примечание: При вызове свойств .user или .auth может возникнуть ошибка WrappedAttributeError. Эти ошибки исходят от аутентификатора как стандартные AttributeError, однако необходимо, чтобы они были повторно вызваны как исключение другого типа, чтобы предотвратить их подавление внешним доступом к свойству. Python не распознает, что AttributeError исходит от аутентификатора, и вместо этого будет считать, что объект запроса не имеет свойства .user или .auth. Аутентификатор необходимо будет исправить.
DRF поддерживает несколько улучшений для браузеров, таких как браузерные формы PUT, PATCH и DELETE.
request.method возвращает упрощенное строковое представление HTTP-метода запроса.
Формы PUT, PATCH и DELETE, основанные на браузере, поддерживаются прозрачно.
Для получения дополнительной информации см. документацию browser enhancements documentation.
request.content_type, возвращает строковый объект, представляющий тип медиа тела HTTP запроса, или пустую строку, если тип медиа не был предоставлен.
Обычно вам не нужно напрямую обращаться к типу содержимого запроса, поскольку вы обычно полагаетесь на стандартное поведение DRF при разборе запроса.
Если вам необходимо получить доступ к типу содержимого запроса, вам следует использовать свойство .content_type, а не request.META.get('HTTP_CONTENT_TYPE'), так как оно обеспечивает прозрачную поддержку неформенного содержимого в браузере.
Для получения дополнительной информации см. документацию browser enhancements documentation.
request.stream возвращает поток, представляющий содержимое тела запроса.
Как правило, вам не понадобится прямой доступ к содержимому запроса, поскольку вы обычно полагаетесь на стандартное поведение DRF при разборе запроса.
Поскольку Request DRF расширяет HttpRequest фреймворка Django, все остальные стандартные атрибуты и методы также доступны. Например, словари request.META и request.session доступны как обычно.
Обратите внимание, что по причинам реализации класс Request не наследуется от класса HttpRequest, а вместо этого расширяет его, используя композицию.