# Запросы ## Запросы > Если вы занимаетесь веб-сервисами на основе 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-данные](/django-rest-framework-russian-documentation/overview/navigaciya-po-api/parsers.md#jsonparser) аналогично тому, как вы обрабатываете входящие [данные формы](/django-rest-framework-russian-documentation/overview/navigaciya-po-api/parsers.md#formparser). Более подробную информацию можно найти в [документации по парсерам](/django-rest-framework-russian-documentation/overview/navigaciya-po-api/parsers.md). ### .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`. Более подробную информацию можно найти в [документации по аутентификации](/django-rest-framework-russian-documentation/overview/navigaciya-po-api/authentication.md). ### .auth `request.auth` возвращает любой дополнительный контекст аутентификации. Точное поведение `request.auth` зависит от используемой политики аутентификации, но обычно это может быть экземпляр токена, по которому был аутентифицирован запрос. Если запрос не аутентифицирован, или если отсутствует дополнительный контекст, значение по умолчанию `request.auth` равно `None`. Более подробную информацию можно найти в [документации по аутентификации](/django-rest-framework-russian-documentation/overview/navigaciya-po-api/authentication.md). ### .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](/django-rest-framework-russian-documentation/stati/topics/browser-enhancements.md). ### .content\_type `request.content_type`, возвращает строковый объект, представляющий тип медиа тела HTTP запроса, или пустую строку, если тип медиа не был предоставлен. Обычно вам не нужно напрямую обращаться к типу содержимого запроса, поскольку вы обычно полагаетесь на стандартное поведение DRF при разборе запроса. Если вам необходимо получить доступ к типу содержимого запроса, вам следует использовать свойство `.content_type`, а не `request.META.get('HTTP_CONTENT_TYPE')`, так как оно обеспечивает прозрачную поддержку неформенного содержимого в браузере. Для получения дополнительной информации см. документацию [browser enhancements documentation](/django-rest-framework-russian-documentation/stati/topics/browser-enhancements.md). ### .stream `request.stream` возвращает поток, представляющий содержимое тела запроса. Как правило, вам не понадобится прямой доступ к содержимому запроса, поскольку вы обычно полагаетесь на стандартное поведение DRF при разборе запроса. *** ## Стандартные атрибуты HttpRequest Поскольку `Request` DRF расширяет `HttpRequest` фреймворка Django, все остальные стандартные атрибуты и методы также доступны. Например, словари `request.META` и `request.session` доступны как обычно. Обратите внимание, что по причинам реализации класс `Request` не наследуется от класса `HttpRequest`, а вместо этого расширяет его, используя композицию. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/overview/navigaciya-po-api/requests.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.