# Запросы ## Запросы > Если вы занимаетесь веб-сервисами на основе REST... вам следует игнорировать request.POST. > > * Malcom Tredinnick, [Django developers group](https://groups.google.com/d/topic/django-developers/dxI4qVzrBY4/discussion) Класс `Request` DRF расширяет стандартный `HttpRequest`, добавляя поддержку гибкого разбора запросов DRF и аутентификации запросов. *** ## Разбор запроса Объекты Request DRF обеспечивают гибкий разбор запросов, что позволяет обрабатывать запросы с данными JSON или другими типами медиа таким же образом, как вы обычно обрабатываете данные формы. ### .data `request.data` возвращает разобранное содержимое тела запроса. Это похоже на стандартные атрибуты `request.POST` и `request.FILES`, за исключением того, что: * Он включает в себя все разобранное содержимое, включая *файловые и нефайловые* входы. * Поддерживается разбор содержимого методов HTTP, отличных от `POST`, что означает, что вы можете получить доступ к содержимому запросов `PUT` и `PATCH`. * Поддерживается гибкий разбор запросов DRF, а не только поддержка данных формы. Например, вы можете обрабатывать входящие [JSON-данные](https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/overview/parsers#jsonparser) аналогично тому, как вы обрабатываете входящие [данные формы](https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/overview/parsers#formparser). Более подробную информацию можно найти в [документации по парсерам](https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/overview/navigaciya-po-api/parsers). ### .query\_params `request.query_params` - это более правильно названный синоним `request.GET`. Для ясности внутри вашего кода мы рекомендуем использовать `request.query_params` вместо стандартного для Django `request.GET`. Это поможет сохранить вашу кодовую базу более корректной и очевидной - любой тип HTTP метода может включать параметры запроса, а не только `GET` запросы. ### .parsers Класс `APIView` или декоратор `@api_view` обеспечат автоматическую установку этого свойства в список экземпляров `Parser` на основе `parser_classes`, установленных в представлении, или на основе настройки `DEFAULT_PARSER_CLASSES`. Обычно вам не требуется доступ к этой собственности. *** **Примечание:** Если клиент посылает недостоверное содержимое, то при доступе к `request.data` может возникнуть ошибка `ParseError`. По умолчанию класс `APIView` или декоратор `@api_view` DRF поймает ошибку и вернет ответ `400 Bad Request`. Если клиент посылает запрос с типом содержимого, который не может быть разобран, то возникает исключение `UnsupportedMediaType`, которое по умолчанию будет поймано и вернет ответ `415 Unsupported Media Type`. *** ## Переговоры по содержанию Запрос раскрывает некоторые свойства, которые позволяют определить результат этапа согласования содержимого. Это позволяет вам реализовать такое поведение, как выбор различных схем сериализации для различных типов носителей. ### .accepted\_renderer Экземпляр рендерера, который был выбран на этапе согласования содержимого. ### .accepted\_media\_type Строка, представляющая тип носителя, который был принят на этапе согласования содержимого. *** ## Аутентификация DRF обеспечивает гибкую аутентификацию по каждому запросу, что дает вам возможность: * Используйте различные политики аутентификации для разных частей вашего API. * Поддерживайте использование нескольких политик аутентификации. * Предоставлять информацию о пользователе и маркере, связанную с входящим запросом. ### .user `request.user` обычно возвращает экземпляр `django.contrib.auth.models.User`, хотя поведение зависит от используемой политики аутентификации. Если запрос не аутентифицирован, значением по умолчанию для `request.user` будет экземпляр `django.contrib.auth.models.AnonymousUser`. Более подробную информацию можно найти в [документации по аутентификации](https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/overview/navigaciya-po-api/authentication). ### .auth `request.auth` возвращает любой дополнительный контекст аутентификации. Точное поведение `request.auth` зависит от используемой политики аутентификации, но обычно это может быть экземпляр токена, по которому был аутентифицирован запрос. Если запрос не аутентифицирован, или если отсутствует дополнительный контекст, значение по умолчанию `request.auth` равно `None`. Более подробную информацию можно найти в [документации по аутентификации](https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/overview/navigaciya-po-api/authentication). ### .authenticators Класс `APIView` или декоратор `@api_view` обеспечат автоматическую установку этого свойства в список экземпляров `Authentication` на основе `authentication_classes`, установленных для представления, или на основе параметра `DEFAULT_AUTHENTICATORS`. Обычно вам не требуется доступ к этой собственности. *** **Примечание:** При вызове свойств `.user` или `.auth` может возникнуть ошибка `WrappedAttributeError`. Эти ошибки исходят от аутентификатора как стандартные `AttributeError`, однако необходимо, чтобы они были повторно вызваны как исключение другого типа, чтобы предотвратить их подавление внешним доступом к свойству. Python не распознает, что `AttributeError` исходит от аутентификатора, и вместо этого будет считать, что объект запроса не имеет свойства `.user` или `.auth`. Аутентификатор необходимо будет исправить. *** ## Улучшения в браузере DRF поддерживает несколько улучшений для браузеров, таких как браузерные формы `PUT`, `PATCH` и `DELETE`. ### .method `request.method` возвращает **упрощенное** строковое представление HTTP-метода запроса. Формы `PUT`, `PATCH` и `DELETE`, основанные на браузере, поддерживаются прозрачно. Для получения дополнительной информации см. документацию [browser enhancements documentation](https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/stati/topics/browser-enhancements). ### .content\_type `request.content_type`, возвращает строковый объект, представляющий тип медиа тела HTTP запроса, или пустую строку, если тип медиа не был предоставлен. Обычно вам не нужно напрямую обращаться к типу содержимого запроса, поскольку вы обычно полагаетесь на стандартное поведение DRF при разборе запроса. Если вам необходимо получить доступ к типу содержимого запроса, вам следует использовать свойство `.content_type`, а не `request.META.get('HTTP_CONTENT_TYPE')`, так как оно обеспечивает прозрачную поддержку неформенного содержимого в браузере. Для получения дополнительной информации см. документацию [browser enhancements documentation](https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/stati/topics/browser-enhancements). ### .stream `request.stream` возвращает поток, представляющий содержимое тела запроса. Как правило, вам не понадобится прямой доступ к содержимому запроса, поскольку вы обычно полагаетесь на стандартное поведение DRF при разборе запроса. *** ## Стандартные атрибуты HttpRequest Поскольку `Request` DRF расширяет `HttpRequest` фреймворка Django, все остальные стандартные атрибуты и методы также доступны. Например, словари `request.META` и `request.session` доступны как обычно. Обратите внимание, что по причинам реализации класс `Request` не наследуется от класса `HttpRequest`, а вместо этого расширяет его, используя композицию.