Начав разработку на Django, мы сталкиваемся с множеством удобных функций (Shortcut). Функции, такие как render(), redirect(), get_object_or_404(), являются благодарными инструментами, повышающими производительность.

Однако, погрузившись в исходный код или написав собственные middleware, в конце концов мы сталкиваемся с одной истиной. "Конец View всегда HttpResponse".

Эта истина, "всё в конечном итоге сводится к HttpResponse", приходит ко всем, кто использует Django. Я считаю, что это важный момент, когда джуниор разработчик переходит на уровень сеньора. Это попытка убрать удобные 'магии (Magic)' фреймворка и понять скрытые 'механизмы'.

Сегодня мы поговорим о сущности класса django.http.response.HttpResponse, который является началом и концом цикла запрос-ответ в Django, и о котором мы порой проходим мимо.

1. Предок всех ответов, HttpResponseBase

Commandbox 광고

Функции View, которые мы пишем, выполняют сложную бизнес-логику, но с точки зрения фреймворка, обязанность View одна. "Принять аргументы и вернуть объект HttpResponse".

Даже удобная функция render() в конечном итоге представляет собой просто обертку, которая преобразует шаблон в строку и возвращает его в HttpResponse.

Понимание этой структуры важно. HttpResponse наследует HttpResponseBase, который является базой для всех классов ответов, которые мы используем, таких как JsonResponse и HttpResponseRedirect.

2. Настоящее за shortcuts

На начальном этапе мы используем только render, но момент, когда нам придется работать с HttpResponse напрямую, inevitably наступит.

Пример: связь между render() и HttpResponse

Ниже приведен два кода, которые в конечном счете отправляют одинаковый HTML клиенту.

# 1. Способ с использованием shortcut (обычный)
from django.shortcuts import render

def home(request):
    return render(request, 'home.html', {'title': 'Home'})

# 2. Основной способ (внутреннее действие)
from django.http import HttpResponse
from django.template import loader

def home(request):
    template = loader.get_template('home.html')
    context = {'title': 'Home'}
    # render() на самом деле в конечном счете создает и возвращает HttpResponse.
    return HttpResponse(template.render(context, request))

Понимание второго способа говорит о том, что вы готовы вмешаться в автоматизированный процесс фреймворка, изменить заголовки или контролировать байтовый поток. И это желание вмешаться возникает все чаще, поэтому вы здесь и читаете этот текст. Вы правильно пришли. Давайте вместе разберемся с HttpResponse.

3. Почему нужно понимать этот класс?

Commandbox 광고

Все изложенное до сих пор близко к утверждению “основа - это HttpResponse”.
Если перейти от среднего уровня к более опытному разработчику, причина понимания этого класса становится более практичной.

  1. Последним виновником странных багов чаще всего является объект ответа.

    • На фронте иногда говорят: “иногда возникает ошибка парсинга JSON,”

    • Во вкладке сети браузера Content-Type установлен странным образом,

    • В логах кодировка испорчена или заголовки установлены дважды.
      Следуя таким проблемам до конца, остаётся лишь один объект HttpResponse.

  2. “Другие лица” Django также происходят от одного предка.

    • Response в DRF также,

    • FileResponse для загрузки файлов также,

    • HttpResponseRedirect для переадресации также
      является лишь разновидностью одной и той же линии.
      Если вы понимаете “предковый класс”, то каждый раз, сталкиваясь с новым классом Response,
      “А, в конечном счете, это тоже его потомок” вы гораздо быстрее уловите контекст.

  3. Становитесь не просто пользователем фреймворка, а тем, кто его ‘расширяет’.
    С любого момента времени мы должны перейти от “поиска и использования доступных функций”
    к “созданию отсутствующих функций и интеграции их в кодовую базу команды”.

    • Создание общего обертки ответа для команды

    • Добавление информации о логах/трейсинге в общие заголовки

    • Возвращение стримингового ответа только при определенных условиях

    Все это происходит значительно более естественно, когда вы понимаете класс, связанный с HttpResponse.

Часто встречающиеся трудности в практике

  • Кастомные middleware
    Middleware перехватывает возвращаемый объект HttpResponse на этапе process_response и изменяет его.
    Независимо от того, добавляете ли вы логирование или заголовки безопасности, в конечном итоге это вопрос о том, как обращаться с объектом ответа.

  • Загрузка файлов и стриминг
    При передаче Excel, PDF, больших CSV, потоков логов необходимо обдумать
    content_type, Content-Disposition, кодировку.

    response = HttpResponse(my_data, content_type="text/csv; charset=utf-8")
response['Content-Disposition'] = 'attachment; filename="report.csv"'
return response

     

  • Настройки безопасности и производительности
    Кэширование, CORS, CSP, Strict-Transport-Security также
    в конечном итоге это строки, которые прикрепляются к заголовку ответа.
    Когда вы решаете, когда, где и как прикрепить эти строки,
    HttpResponse больше не “автоматически генерируемое что-то”, а
    “продукт, который я собираю с намерением”.

4. В заключение: Стать человеком, который обращается с HTTP за пределами Django

На некотором этапе мы больше не можем быть описаны только как “разработчики Django”.
Шаблоны, ORM, маршрутизация URL уже стали для нас привычными, и теперь мы начинаем задавать такие вопросы.

“Что именно я действительно обрабатываю в этом проекте?”

Один из ответов на этот вопрос — это тема данного текста.
То, с чем мы действительно работаем, это HTTP-ответ, а не код Python.
Django лишь огромная фабрика для его создания,
а финальный продукт на последнем конвейере фабрики — это HttpResponse.

С точки зрения опытного разработчика Django, я считаю этот момент маленьким развилкой.

  • Начинаем не просто смотреть на render(), а задаться вопросом:
    “Какой HttpResponse на самом деле создается в этот момент?”.

  • Когда видим баг, и не останавливаемся на вопросе “проблема в шаблоне?”,
    а задаем вопрос: “Точные ли финальные заголовки ответа, тело, кодировка, статус-код?”.

  • При просмотре DRF, ASGI, других веб-фреймворков
    начинаем сначала исследовать их как они генерируют Response.

С этого момента мы становимся не просто теми, кто ездит за фреймворком,
человеком, который проектирует, как передавать данные по сети.

Концепция Django HttpResponse

Завершая статью, хочу предложить одну мысль.

В следующий раз, когда будете писать view, рекомендую задуматься над таким эксперименты.

“Как выглядел бы этот код, если бы я реализовал его только с помощью HttpResponse, без использования Django shortcuts?”

Скорее всего, поначалу это покажется неудобным и громоздким.
Но пройдя через этот процесс пару раз,
вы начнете замечать те моменты, которые раньше воспринимались как ‘само собой разумеющееся’.

Только тогда HttpResponse начинает выглядеть не как простейший класс из документации,
а как настоящее лицо веб-приложения, с которым мы ежедневно взаимодействуем, но о котором не задумывались.

И разработчик, который по-настоящему понимает это лицо,
меньше колеблется, когда фреймворк меняется,
где бы он ни находился, в любой технологической стеке,
никогда не теряет осознания того, что “в конце всегда есть ответ”.

Я верю, что именно в этот момент мы становимся на шаг глубже как опытные разработчики.