Согласование контента
Согласование контента
HTTP предусматривает несколько механизмов "согласования контента" - процесса выбора наилучшего представления для данного ответа при наличии нескольких представлений.
RFC 2616, Fielding et al.
Согласование контента - это процесс выбора одного из нескольких возможных форматов ответа для возврата клиенту, основанный на предпочтениях клиента или сервера.
Определение выбранного рендерера
DRF использует простой стиль согласования контента для определения того, какой формат данных должен быть возвращен клиенту, основываясь на доступных рендерерах, приоритетах каждого из них и заголовке клиента Accept:
. Используемый стиль частично зависит от клиента, а частично от сервера.
Более конкретным типам носителей отдается предпочтение перед менее конкретными типами носителей.
Если несколько типов медиа имеют одинаковую специфичность, то предпочтение отдается на основе порядка рендеринга, настроенного для данного представления.
Например, при следующем заголовке Accept
:
Приоритеты для каждого из указанных типов носителей будут следующими:
'application/json; indent=4'
'application/json'
,'application/yaml'
и'text/html'
*/*
Если запрашиваемое представление было настроено только с рендерерами для YAML
и HTML
, то DRF будет выбирать тот рендерер, который указан первым в списке renderer_classes
или настройке DEFAULT_RENDERER_CLASSES
.
Более подробную информацию о заголовке HTTP Accept
смотрите в RFC 2616.
Примечание: Значения "q" не учитываются DRF при определении предпочтений. Использование значений "q" негативно влияет на кэширование, и, по мнению автора, это ненужный и слишком сложный подход к согласованию контента.
Это верный подход, поскольку спецификация HTTP намеренно не определяет, как сервер должен взвешивать предпочтения, основанные на сервере, против предпочтений, основанных на клиенте.
Переговоры по пользовательскому контенту
Маловероятно, что вы захотите предоставить пользовательскую схему согласования контента для DRF, но вы можете сделать это при необходимости. Для реализации пользовательской схемы согласования контента переопределите BaseContentNegotiation
.
Классы согласования контента DRF обрабатывают выбор как подходящего парсера для запроса, так и подходящего рендерера для ответа, поэтому вы должны реализовать оба метода .select_parser(request, parsers)
и .select_renderer(request, renderers, format_suffix)
.
Метод select_parser()
должен вернуть один экземпляр парсера из списка доступных парсеров, или None
, если ни один из парсеров не может обработать входящий запрос.
Метод select_renderer()
должен возвращать кортеж из (экземпляр рендерера, тип медиа), либо вызывать исключение NotAcceptable
.
Пример
Ниже представлен пользовательский класс согласования контента, который игнорирует запрос клиента при выборе подходящего парсера или рендерера.
Указание согласования контента
Класс согласования контента по умолчанию можно установить глобально, используя настройку DEFAULT_CONTENT_NEGOTIATION_CLASS
. Например, следующие настройки будут использовать наш пример класса IgnoreClientContentNegotiation
.
Вы также можете указать согласование контента, используемое для отдельного представления или набора представлений, используя представления на основе класса APIView
.
Last updated