Условная обработка представлений

Декоратор condition

Иногда (на самом деле, довольно часто) можно создать функции для быстрого вычисления значения ETag или времени последнего изменения ресурса, не выполняя все вычисления, необходимые для создания полного представления. Тогда Django сможет использовать эти функции для досрочного прекращения обработки представления. Например, чтобы сообщить клиенту, что содержимое не изменилось с момента последнего запроса.

Эти две функции передаются в качестве параметров декоратору django.views.decorators.http.condition. Декоратор использует обе функции (достаточно указать одну, если быстро и просто вычислить обе величины невозможно), чтобы определить, соответствуют ли заголовки HTTP-запроса заголовкам ресурса. Если они не соответствуют, необходимо вычислить новую копию ресурса и вызвать обычное представление.

Сигнатура декоратора condition выглядит так:

condition(etag_func=None, last_modified_func=None)

Функции для вычисления ETag и времени последнего изменения получат входящий объект request и те же параметры в том же порядке, что и оборачиваемая ими функция представления. Функция, переданная в last_modified_func, должна возвращать стандартное значение datetime, указывающее время последнего изменения ресурса, или None, если ресурс не существует. Функция, переданная декоратору etag, должна возвращать строку, представляющую ETag ресурса, или None, если ресурс не существует.

Декоратор устанавливает заголовки ETag и Last-Modified, если представление не установило их ранее и метод запроса является безопасным (GET или HEAD).

Лучше всего объяснить практическое применение этой возможности на примере. Предположим, у вас есть следующая пара моделей, представляющая небольшую блоговую систему:

import datetime
from django.db import models


class Blog(models.Model): ...


class Entry(models.Model):
    blog = models.ForeignKey(Blog, on_delete=models.CASCADE)
    published = models.DateTimeField(default=datetime.datetime.now)
    ...

Если главная страница с последними записями блога изменяется только при добавлении новой записи, время последнего изменения можно вычислить очень быстро. Для этого нужно найти самую позднюю дату published для каждой записи, связанной с этим блогом. Один из способов сделать это:

def latest_entry(request, blog_id):
    return Entry.objects.filter(blog=blog_id).latest("published").published

Затем эту функцию можно использовать для раннего определения того, что главная страница не изменилась:

from django.views.decorators.http import condition


@condition(last_modified_func=latest_entry)
def front_page(request, blog_id): ...

Упрощённые варианты для вычисления только одного значения

Как правило, если вы можете предоставить функции для вычисления обоих значений — ETag и времени последнего изменения, — вам следует это сделать. Нельзя заранее знать, какие заголовки отправит тот или иной HTTP-клиент, поэтому нужно быть готовым обработать оба варианта. Однако иногда легко вычислить только одно значение, и Django предоставляет декораторы, которые обрабатывают только вычисление ETag или времени последнего изменения.

Декораторам django.views.decorators.http.etag и django.views.decorators.http.last_modified передаются функции того же типа, что и декоратору condition. Их сигнатуры:

etag(etag_func)
last_modified(last_modified_func)

Предыдущий пример, в котором используется только функция определения времени последнего изменения, можно записать с помощью одного из этих декораторов:

@last_modified(latest_entry)
def front_page(request, blog_id): ...

…или так:

def front_page(request, blog_id): ...


front_page = last_modified(latest_entry)(front_page)

# Bad code. Don't do this!
@etag(etag_func)
@last_modified(last_modified_func)
def my_view(request): ...


# End of bad code.

Использование декораторов с другими методами HTTP

Декоратор condition полезен не только для запросов GET и HEAD (в этой ситуации запросы HEAD эквивалентны запросам GET). Его также можно использовать для проверки запросов POST, PUT и DELETE. В этих случаях цель состоит не в том, чтобы вернуть ответ «не изменено», а в том, чтобы сообщить клиенту, что ресурс, который он пытается изменить, за это время был изменён.

Например, рассмотрим следующий обмен данными между клиентом и сервером:

1. Клиент запрашивает /foo/.
2. Сервер отвечает некоторым содержимым с ETag "abcd1234".
3. Клиент отправляет HTTP-запрос PUT на /foo/, чтобы обновить ресурс. Он также отправляет заголовок If-Match: "abcd1234", указывая версию, которую пытается обновить.
4. Сервер проверяет, изменился ли ресурс, вычисляя ETag тем же способом, что и для запроса GET (с помощью той же функции). Если ресурс изменился, сервер возвращает код состояния 412, означающий «предварительное условие не выполнено».
5. Получив ответ 412, клиент отправляет запрос GET на /foo/, чтобы получить обновлённую версию содержимого перед его изменением.

Этот пример показывает, что одни и те же функции можно использовать для вычисления ETag и времени последнего изменения во всех ситуациях. Более того, вам следует использовать одни и те же функции, чтобы каждый раз возвращались одинаковые значения.

Сравнение с условной обработкой в промежуточном слое

Django предоставляет обработку условных запросов GET с помощью django.middleware.http.ConditionalGetMiddleware. Хотя промежуточный слой подходит для многих ситуаций, при более сложном использовании у него есть ограничения:

• Он применяется глобально ко всем представлениям проекта.
• Он не избавляет от генерации ответа, которая может быть затратной.
• Он подходит только для HTTP-запросов GET.

Выбирайте наиболее подходящий инструмент для конкретной задачи. Если вы можете быстро вычислять ETag и время изменения, а генерация содержимого каким-либо представлением занимает заметное время, рассмотрите возможность использования описанного в этом документе декоратора condition. Если всё и так выполняется достаточно быстро, используйте промежуточный слой: он всё равно уменьшит объём сетевого трафика, отправляемого клиентам, если представление не изменилось.