[БЕЗ_ЗВУКА] В
этом видео мы рассмотрим процесс
обработки запроса, роутинг, устройство view,
HttpRequest и HttpResponse, декораторы и их применение в веб-приложениях.
Рассмотрим процесс обработки запроса: когда
мы запрашиваем какой-то веб-сервис, то с самого начала запрос попадает в urls,
там находит необходимый обработчик запроса, которому передается управление.
Там выполняется какая-то бизнес-логика,
формируется ответ клиенту и, собственно, передается клиенту.
Давайте поподробнее рассмотрим процесс, который происходит внутри urls.
При старте приложения django загружает модуль,
который указан в root_urlconf, который указан в файлике settings.
А потом внутри него ищет переменное urlpatterns.
Когда djang'е приходит запрос,
она проверяет по порядку каждое регулярное выражение, которое указано в urlpatterns.
В случае, если он нашел совпадение,
то вызывает соответствующий этому url'у обработчик,
который передает объект httprequest'а и параметр,
который нашло регулярное выражение.
Если он просканил все url'ы и не нашел совпадения,
то django вызывает соответствующий обработчик ошибки.
Давайте рассмотрим процесс роутинга.
Что такое роутинг?
Это сопоставление url'а с его обработчиком.
Это описано в файликах urls и переменной urlpatterns.
Urlpatterns представляет из себя массив из объектов urls.
Когда мы создаем объект urls, то мы указываем там регулярное выражение,
которое соответствует url'у и его обработчик.
Давайте рассмотрим на примере.
Например, мы делаем запрос какому-то сервису /articles/2003/.
Мы тестируем первый url, видим, что он совпадает,
будет вызван обработчик с параметром request.
Теперь давайте рассмотрим запрос /articles/2004/.
Мы тестируем первое регулярное выражение, видно,
что оно не подходит, тестируем второе — видно, что оно подходит.
Управление передастся второму обработчику с request и с одним
найденным параметром 2004.
То же самое произойдет и в третьем примере.
Следует рассмотреть четвертый пример, где в группах указано их имя.
И когда мы, например, сделаем запрос /articles/2005/12/01,
то вызовется соответсвующий
обработчик с параметрами request и позиционными
параметрами year, month и day.
Важно отметить, что,
если внутри регулярного выражения были именнованные аргументы,
то неименнованные будут игнорироваться.
Найденные аргументы всегда будут строки — это надо учитывать при написании view.
Каждое регулярное выражение компилируется только один раз,
и это не влияет на производительность.
Рассмотрим, что такое include.
С помощью include мы можем организовать некую такую иерархическую структуру,
то есть, мы указываем в переменной urlpatterns такой url,
который в начале соответствует некому префиксу, и далее мы указываем include,
либо переменную, которая содержит список из url'ов,
либо файлик, в котором есть переменная urlpatterns.
Зачем это нужно?
Допустим, у нас есть множество url'ов с одинаковым префиксом,
и очень длинным, и в котором указываются некоторые параметры.
И этот префикс содержится во множестве url'ов, которые не хочется повторять.
Для этого мы делаем url, в котором мы указываем этот префикс и дальше
пишем include, а внутри этому include'у передаем список url'ов,
в котором указаны только те части, которые отличаются.
Это очень удобно на практике.
После того, как мы с помощью urls определили обработчик,
которому следует передать обработку этого запроса, он будет вызван.
Давайте рассмотрим его структуру.
Обработчик, то есть view.
Каждое view принимает объект HttpRequest в качестве своего первого параметра,
который обычно называется в коде request.
Также каждое view должна возвращать объект HttpResponse,
который содержит сгенерированный ответ.
Давайте поподробнее рассмотрим объект HttpRequest.
Нам интересны его атрибуты, такие как method, в котором содержится метод
Http запроса; атрибут GET, в котором содержатся get параметры; атрибут POST,
в котором содержится тело запроса; и атрибут FILES,
в котором содержатся файлики, которые переданы с запроса.
Также атрибут COOKIES, в котором указаны cookie запросы,
и атрибут META, в котором указаны заголовки нашего запроса.
Теперь HttpResponse.
Рассмотрим его конструктор, собственно,
когда мы формируем тело ответа, мы создаем HttpResponse и его возвращаем.
Первое — это content, это тело нашего ответа.
Затем content_type — это тип MIME, тип данных, которые мы будем возвращать.
status — это статус нашего http ответа, например, ok,
not found, bad request и так далее.
reason — это в случае, если мы хотим как-то предопределить reason в http,
то мы его передаем, иначе он возьмется из статуса http ответа.
И charset — это собственная кодировка, с которой будут переданы данные клиенту.
Также рассмотрим, что можно делать с объектом HttpResponse.
Для того чтобы установить некоторые заголовки
в HttpResponse, то можно с ним работать так же, как со словарем.
То есть мы указываем ключик и присваиваем ему какое-то значение.
Чтобы удалить этот заголовок, это так же работает, как в словаре.
То есть, мы пишем delete и указываем объект и ключик нашего заголовка.
Если мы хотим проверить, существует ли наш заголовок в этом ответе,
то мы вызываем метод has header.
Если нам нужно установить или удалить cookie,
нам нужно вызвать методы set cookie и delete cookie соответственно.
В случае, если нам нужно в процессе обработки запроса формировать ответ,
то можно вызвать у HttpResponse'а метод write и дописывать ответ.
Теперь рассмотрим декораторы и их применение в веб-приложении.
Рассмотрим пример.
Допустим, в множестве запросов нам нужно всегда проверять,
что Http method, с которым пришел запрос, является get.
То каждый раз нам придется во view писать условие if request
method не равняется get return http method not allowed.
Это не удобно.
Это дублирование кода, это делать плохо.
В этом случае, очень удобно применить декоратор.
Мы просто делаем декоратор, в котором добавляем логику проверки,
что нам пришел get запрос, и вешаем этот декоратор на все наши обработчики.
В django'е поставляется несколько стандартных декораторов, например, тот,
что мы уже рассмотрели, это require http method,
которому можно передать список методов, которым разрешена обработка этой view.
Или например short cut'ы.
require_GET, который резрешает только обработку get запросов,
или require_POST, который разрешает обработку только post запросов.
В итоге, в этом видео мы рассмотрели процесс обработки запроса, роутинг,
устройства view, HttpRequest и HttpResponse и декораторы и их применения.
[ЗВУК] [БЕЗ_ЗВУКА]
Абрамов Тимур
Пестров Никита
Опрышко Александр
Партилов Алексей
