что такое request в django
Путь от request до response в Джанго
Веб-приложение или веб-сайт вращаются вокруг цикла запрос-ответ, и приложения Django не являются исключением. Но это не просто двухэтапный процесс. Наши приложения Django должны пройти различные стадии, чтобы вернуть конечному пользователю результат. Чтобы лучше понять структуру Django, мы должны понимать, как инициируются запросы и как конечный результат передается конечному пользователю. В следующих разделах я собираюсь объяснить различные этапы запросов и используемое там программное обеспечение или код.
При настройке нового проекта Django первое, что вы сделаете, это подключите ваши URLconfs и создадите какие-то представления. Но что на самом деле происходит «под капотом»? Как Django направляет трафик к представлению и какую роль играют промежуточное ПО (middleware) в этом цикле?
WSGI — это инструмент, созданный для решения основной проблемы: подключения веб-сервера к веб-среде. WSGI имеет две стороны: «серверная» и «прикладная». Для обработки ответа WSGI сервер выполняет приложение и предоставляет функцию обратного вызова на стороне приложения. Приложение обрабатывает запрос и возвращает ответ на сервер, используя предоставленный обратный вызов. По сути, обработчик WSGI действует как привратник между вашим веб-сервером (Apache, NGINX и т.д.) и вашим проектом на Django.
Между сервером и приложением лежат промежуточные программы (middleware). Вы можете думать о промежуточном программном обеспечении как о серии двунаправленных фильтров: они могут изменять (или замыкать) данные, передаваемые назад и вперед между сетью и вашим приложением Django.
Большая картина — поток данных
Когда пользователь делает запрос к вашему приложению, создается экземпляр обработчика WSGI, который:
Слои приложения Джанго
Всякий раз, когда поступает запрос, он обрабатывается промежуточным программным обеспечением. Мы можем иметь несколько промежуточных программ. Найти их можно в настройках проекта ( settings.py ). Промежуточное ПО запросов Django происходит по порядку при обработке запроса. Предположим, что если у нас есть запрос промежуточного программного обеспечения в порядке A, B, C, то запрос сначала обрабатывается промежуточным программным обеспечением A, а затем B, а затем C. Django предлагает связку промежуточного программного обеспечения по умолчанию. Мы также можем написать наши собственные или пользовательские промежуточные программы. После обработки запроса промежуточным программным обеспечением он будет отправлен на маршрутизатор URL (диспетчер URL).
URL-маршрутизатор примет запрос от промежуточного программного обеспечения запроса (request middleware) и получит путь URL-адреса из запроса. На основе пути URL-маршрутизатор попытается сопоставить путь запроса с доступными шаблонами URL-адреса. Эти шаблоны URL имеют форму регулярных выражений. После сопоставления пути URL с доступными шаблонами URL запрос будет отправлен в представление, связанное с URL.
Теперь мы находимся в слое бизнес-логики. Представления обрабатывают бизнес-логику, используя запрос и данные запроса (данные, отправленные в GET, POST и т.д.). После обработки в представлении запрос отправляется контекстным процессорам, с помощью обработчиков контекста запроса добавляет контекстные данные, которые помогут средству визуализации шаблонов визуализировать шаблон для генерации HTTP-ответа.
И снова запрос будет отправлен обратно в промежуточное программное обеспечение, но уже ответа ( response ) для его обработки. Промежуточное программное обеспечение ответа обработает запрос и добавит или изменит информацию заголовка /информацию тела перед отправкой обратно клиенту (браузеру). После этого браузер обработает и отобразит его для конечного пользователя.
Промежуточное программное обеспечение используется в ряде ключевых функций в проекте Django: например мы используем промежуточное ПО CSRF для предотвращения атак подделки межсайтовых запросов. Они используются для обработки данных сеанса. Аутентификация и авторизация осуществляется с использованием промежуточного программного обеспечения. Мы можем написать наши собственные классы промежуточного программного обеспечения для формирования (или замыкания) потока данных через ваше приложение.
process_request
Определение URL
Представление имеет три требования:
process_view
Теперь, когда обработчик WSGI знает, какую функцию представления вызывать, он снова просматривает свой список методов промежуточного программного обеспечения. Метод process_view для любого промежуточного программного обеспечения Django объявлен так:
process_exception
process_response
Все сделано!
Наконец, обработчик Django WSGI создает возвращаемое значение из объекта HttpResponse и выполняет функцию обратного вызова для отправки этих данных на веб-сервер и для пользователя.
Итак, два ключевых вывода:
Учебник 2: Запросы и ответы¶
С этого момента мы действительно начнем освещать суть фреймворка REST. Давайте представим несколько основных строительных блоков.
Объекты запроса¶
Объекты реагирования¶
Коды состояния¶
Обертывание представлений API¶
Фреймворк REST предоставляет две обертки, которые можно использовать для написания представлений API.
Декоратор @api_view для работы с представлениями, основанными на функциях.
Класс APIView для работы с представлениями, основанными на классах.
Собираем все вместе¶
Итак, давайте начнем использовать эти новые компоненты, чтобы немного рефакторизовать наши представления.
Наше представление экземпляра является улучшением по сравнению с предыдущим примером. Оно немного лаконичнее, и код теперь очень похож на тот, который мы использовали при работе с Forms API. Мы также используем именованные коды состояния, что делает значения ответов более очевидными.
Добавление необязательных суффиксов формата к нашим URL-адресам¶
Начните с добавления аргумента в виде ключевого слова format к обоим представлениям, как показано ниже.
Нам не обязательно добавлять эти дополнительные шаблоны url, но это дает нам простой и чистый способ ссылаться на определенный формат.
Как он выглядит?¶
Мы можем получить список всех сниппетов, как и раньше.
Мы можем контролировать формат ответа, который мы получаем обратно, либо с помощью заголовка Accept :
Или путем добавления суффикса формата:
Удобство просмотра¶
Поскольку API выбирает тип содержимого ответа на основе запроса клиента, он по умолчанию возвращает представление ресурса в формате HTML, когда ресурс запрашивается веб-браузером. Это позволяет API возвращать полностью доступное для веб-браузера представление HTML.
Что дальше?¶
В :doc: ` tutorial part 3 `** мы начнем использовать представления, основанные на классах, и увидим, как общие представления уменьшают количество кода, который нам нужно написать.
Объекты запроса и ответа ¶
Краткий обзор ¶
Django использует объекты запроса и ответа для передачи состояния через систему.
Когда страница запрашивается, Django создает HttpRequest объект, содержащий метаданные о запросе. Затем Django загружает соответствующее представление, передавая в HttpRequest качестве первого аргумента функции представления. Каждое представление отвечает за возврат HttpResponse объекта.
В этом документе описываются интерфейсы API для HttpRequest и HttpResponse объектов, которые определены в django.http модуле.
HttpRequest объекты ¶
Атрибуты ¶
Все атрибуты должны считаться доступными только для чтения, если не указано иное.
Строка, представляющая схему запроса ( http или https обычно).
Строка, представляющая полный путь к запрошенной странице, не включая схему или домен.
Строка, представляющая метод HTTP, используемый в запросе. Гарантируется, что это будет верхний регистр. Например:
Строка, представляющая MIME-тип запроса, извлеченная из CONTENT_TYPE заголовка.
Словарь параметров «ключ-значение», включенных в CONTENT_TYPE заголовок.
Подобный словарю объект, содержащий все заданные параметры HTTP GET. См. QueryDict Документацию ниже.
Подобный словарю объект, содержащий все заданные параметры HTTP POST, при условии, что запрос содержит данные формы. См. QueryDict Документацию ниже. Если вам нужно получить доступ к необработанным данным или данным, не относящимся к форме, опубликованным в запросе, используйте HttpRequest.body вместо этого атрибут.
Словарь, содержащий все файлы cookie. Ключи и значения представляют собой строки.
См. Раздел Управление файлами для получения дополнительной информации.
FILES будет содержать данные только в том случае, если метод запроса был POST, а метод
Объекты запроса и ответа¶
Краткая информация¶
Django использует объекты запроса и ответа для передачи состояния через систему.
Объекты HttpRequest ¶
Атрибуты¶
Все атрибуты должны считаться доступными только для чтения, если не указано иное.
Строка, представляющая схему запроса (обычно http или https ).
Строка, представляющая полный путь к запрошенной странице, не включая схему или домен.
В некоторых конфигурациях веб-сервера часть URL-адреса после имени хоста разделяется на часть префикса сценария и часть информации о пути. Атрибут path_info всегда содержит часть пути с информацией о пути, независимо от того, какой веб-сервер используется. Использование этого вместо path может упростить перенос вашего кода между тестовым сервером и сервером развертывания.
Строка, представляющая метод HTTP, используемый в запросе. Это гарантированно будет в верхнем регистре. Например:
Словарный объект, содержащий все заданные параметры HTTP GET. Смотрите документацию QueryDict ниже.
Словарь, содержащий все файлы cookie. Ключи и значения представляют собой строки.
Смотрите Управление файлами для получения дополнительной информации.
Словарь, содержащий все доступные заголовки HTTP. Доступные заголовки зависят от клиента и сервера, но вот несколько примеров:
Название каждого заголовка стилизовано с заглавной буквой (например, User-Agent ) при отображении. Вы можете обращаться к заголовкам без учета регистра:
Для использования, например, в шаблонах Django, заголовки также можно искать с помощью подчеркивания вместо дефисов:
Атрибуты, установленные кодом приложения¶
Django сам не устанавливает эти атрибуты, но использует их, если они установлены вашим приложением.
Будет использоваться вместо DEFAULT_EXCEPTION_REPORTER_FILTER для текущего запроса. Смотрите Пользовательские отчеты об ошибках для подробностей.
Будет использоваться вместо DEFAULT_EXCEPTION_REPORTER для текущего запроса. Смотрите Пользовательские отчеты об ошибках для подробностей.
Атрибуты, установленные промежуточным программным обеспечением middleware¶
Из SessionMiddleware : читаемый и записываемый, подобный словарю объект, представляющий текущий сеанс.
Методы¶
Метод get_host() не работает, когда хост находится за несколькими прокси. Одним из решений является использование промежуточного программного обеспечения middleware для перезаписи заголовков прокси, как в следующем примере:
Возвращает исходный порт запроса, используя информацию из переменных HTTP_X_FORWARDED_PORT (если USE_X_FORWARDED_PORT включен) и SERVER_PORT и META в указанном порядке.
Возвращает path плюс добавленную строку запроса, если применимо.
HttpRequest. build_absolute_uri ( location = None ) [исходный код] ¶
Если местоположение уже является абсолютным URI, оно не будет изменено. В противном случае абсолютный URI создается с использованием переменных сервера, доступных в этом запросе. Например:
Совмещение HTTP и HTTPS на одном сайте не рекомендуется, поэтому build_absolute_uri() всегда будет генерировать абсолютный URI с той же схемой, что и текущий запрос. Если вам нужно перенаправить пользователей на HTTPS, лучше всего позволить вашему веб-серверу перенаправлять весь HTTP-трафик на HTTPS.
Смотрите криптографическая подпись для получения дополнительной информации.
HttpRequest. accepts ( mime_type )¶
Не рекомендуется, начиная с версии 3.1.
HttpRequest. read ( size = None ) [исходный код] ¶ HttpRequest. readline () [исходный код] ¶ HttpRequest. readlines () [исходный код] ¶ HttpRequest. __iter__ () [исходный код] ¶
Учитывая этот стандартный интерфейс, экземпляр HttpRequest может быть передан непосредственно в синтаксический анализатор XML, например ElementTree :
Объекты QueryDict ¶
Методы¶
QueryDict реализует все стандартные методы словаря, потому что это подкласс словаря. Здесь указаны исключения:
Если query_string не передан, результирующий QueryDict будет пустым (у него не будет ключей или значений).
Устанавливает для данного ключа значение [значение] (список, единственным элементом которого является значение ). Обратите внимание, что это, как и другие словарные функции, которые имеют побочные эффекты, можно вызывать только в изменяемом QueryDict (например, в том, который был создан с помощью QueryDict.copy() ).
QueryDict. __contains__ ( key )¶
QueryDict. update ( other_dict )¶
Кроме того, QueryDict имеет следующие методы:
Устанавливает для данного ключа значение list_ (в отличие от __setitem__() ).
Добавляет элемент во внутренний список, связанный с ключом.
Удаляет произвольный член словаря (поскольку нет концепции упорядочивания) и возвращает кортеж из двух значений, содержащий ключ и список всех значений для ключа. Вызывает ошибку KeyError при вызове пустого словаря. Например:
Возвращает строку данных в формате строки запроса. Например:
Используйте параметр safe для передачи символов, не требующих кодирования. Например:
Объекты HttpResponse ¶
Применение¶
Передача строк¶
Но если вы хотите добавлять контент постепенно, вы можете использовать response как файловый объект:
Передача итераторов¶
Настройка полей заголовка¶
Чтобы установить или удалить поле заголовка в своем ответе, используйте HttpResponse.headers :
Вы также можете управлять заголовками, рассматривая свой ответ как словарь:
Вы также можете установить заголовки при создании экземпляра:
Поля заголовка HTTP не могут содержать символы новой строки. Попытка установить поле заголовка, содержащее символ новой строки (CR или LF), вызовет ошибку BadHeaderError
Добавлена возможность задавать заголовки при создании экземпляра.
Указание браузеру рассматривать ответ как вложение файла¶
В заголовке Content-Disposition нет ничего специфичного для Django, но его синтаксис легко забыть, поэтому мы включили его здесь.
Атрибуты¶
Строка байтов, представляющая содержимое, при необходимости закодированное из строки.
Фраза причины HTTP для ответа. Он использует фразы причины по умолчанию HTTP standard’s.
Этот атрибут существует, поэтому промежуточное ПО может обрабатывать потоковые ответы иначе, чем обычные ответы.
True`, если ответ был закрыт.
Методы¶
Создает экземпляр объекта HttpResponse с заданным содержимым страницы, типом содержимого и заголовками.
content чаще всего представляет собой итератор, строку байтов, memoryview или строку. Другие типы будут преобразованы в байтовую строку путем кодирования их строкового представления. Итераторы должны возвращать строки или байтовые строки, и они будут объединены вместе для формирования содержимого ответа.
Устанавливает заданное имя заголовка в заданное значение. header и value должны быть строками.
HttpResponse. __delitem__ ( header )¶
Удаляет заголовок с заданным именем. Если заголовок не существует, происходит автоматическая ошибка. Без учета регистра.
HttpResponse. __getitem__ ( header )¶
Возвращает значение для заданного имени заголовка. Без учета регистра.
HttpResponse. has_header ( header )¶
Возвращает True или False на основе проверки без учета регистра для заголовка с заданным именем.
Действует как dict.items() для заголовков HTTP в ответе.
Устанавливает заголовок, если он еще не установлен.
Устанавливает cookie. Параметры такие же, как и в объекте cookie Morsel в стандартной библиотеке Python.
max_age должен быть целым числом секунд или None (по умолчанию), если cookie должен длиться только в течение сеанса браузера клиента. Если срок действия не указан, он будет рассчитан.
Используйте samesite=’None’ (строка), чтобы явно указать, что этот файл cookie отправляется со всеми запросами на одном сайте и между сайтами.
Было разрешено использование samesite=’None’ (строка).
RFC 6265 утверждает, что пользовательские агенты должны поддерживать файлы cookie размером не менее 4096 байт. Для многих браузеров это также максимальный размер. Django не вызовет исключение, если есть попытка сохранить cookie размером более 4096 байт, но многие браузеры не будут правильно устанавливать cookie.
Было разрешено использование samesite=’None’ (строка).
Удаляет куки с заданным ключом. Если ключ не существует, то никаких ошибок не вызывает.
Этот метод вызывается в конце запроса непосредственно сервером WSGI.
Этот метод делает экземпляр HttpResponse файловым объектом.
Этот метод делает экземпляр HttpResponse файловым объектом.
Этот метод делает экземпляр HttpResponse файловым объектом.
HttpResponse. writelines ( lines ) [исходный код] ¶
Записывает в ответ список строк. Разделители строк не добавляются. Этот метод делает экземпляр HttpResponse подобным потоку объектом.
Подклассы HttpResponse ¶
Этот доступный только для чтения атрибут представляет URL-адрес, на который будет перенаправлен ответ (эквивалент заголовка ответа Location ).
Конструктор не принимает никаких аргументов, и к этому ответу не следует добавлять содержимое. Используйте, чтобы указать, что страница не изменялась с момента последнего запроса пользователя (код состояния 304).
Пользовательские классы ответа¶
Объекты JsonResponse ¶
Его заголовок Content-Type по умолчанию имеет значение application/json.
Применение¶
Типичное использование может выглядеть так:
Сериализация не словарных объектов¶
Изменение кодировщика JSON по умолчанию¶
Если вам нужно использовать другой класс кодировщика JSON, вы можете передать параметр encoder методу конструктора:
Объекты StreamingHttpResponse ¶
Django разработан для краткосрочных запросов. Потоковая передача ответов свяжет рабочий процесс на все время ответа. Это может привести к снижению производительности.
Вообще говоря, вам следует выполнять дорогостоящие задачи вне цикла запрос-ответ, а не прибегать к потоковому ответу.
StreamingHttpResponse следует использовать только в ситуациях, когда абсолютно необходимо, чтобы весь контент не повторялся перед передачей данных клиенту. Поскольку доступ к контенту невозможен, многие промежуточные программы не могут нормально работать. Например, заголовки ETag и Content-Length не могут быть созданы для потоковых ответов.
Атрибуты¶
Фраза причины HTTP для ответа. Он использует фразы причины по умолчанию HTTP standard’s.
Объекты FileResponse ¶
FileResponse принимает любой файловый объект с двоичным содержимым, например файл, открытый в двоичном режиме, например:
Файл будет закрыт автоматически, поэтому не открывайте его с помощью диспетчера контекста.
Методы¶
Аргумент request в функциях Django?
Я хочу получить адрес текущего юзера, для подмены им моего хардкода. Пробую стандартный подход
И действительно откуда берется в джанговских вьюхах request и почему в моем случае его не хватает?
Я попробовал связать вьюху с url
Но результат тотже
Как-то слишком много магии.
Неужели вы не понимаете, что request не самозарождается внутри функции, как дети в капусте?!
потому что джанга может НЕ ТОЛЬКО REQUEST передать в функцию, будете потом тупить, «а почему у меня user_id пишет что не поместилось».
НЕЛЬЗЯ «№;%% В ВОЗДУХЕ НАПИСАТЬ blabla(request) И ЖДАТЬ ЧТО REQUEST САМОЗАРОДИТСЯ ИЗ НИЧЕГО.
И вообще, у меня сильное ощущение, что вам на три-четыре месяца надо отложить Django и выучить сам питон для начала.
Неужели вы не понимаете, что request не самозарождается внутри функции, как дети в капусте?!
И вообще, у меня сильное ощущение, что вам на три-четыре месяца надо отложить Django и выучить сам питон для начала
хм, может и так конечно, но не понимаю как вы сделали такой вывод основываясь на отсутствие у меня глубокого опыта работы с одним из многих python фреймворком
А за объяснение спасибо! Правильно я понимаю, что не передается request потому что я напрямую пытаюсь обратиться к функции а не к url?
Вы создали функцию с обязательным позиционным аргументом
def current_user(request):
после этого вызвали ее без передачи этого аргумента
current_user()
и после этого спрашиваете как я сделал этот вывод?!
Правильно я понимаю, что не передается request потому что я напрямую пытаюсь обратиться к функции а не к url?