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

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

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

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

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

Функции 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. Почему нужно понимать этот класс?

Все изложенное до сих пор близко к утверждению “основа - это 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
Концепция Django HttpResponse

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

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

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

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

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

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

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