На проверке API обнаружено: ответ зависит от заголовка Accept, но Vary: Accept отсутствует. Какое последствие должен выявить интеграционный тест?
Интеграционный тест должен выявить риск выдачи клиенту представления, предназначенного для другого значения Accept. Без Vary: Accept общий кэш может сохранить ответ для одного формата и вернуть его клиенту, запросившему другой формат.
HTTP допускает несколько представлений одного ресурса: например, JSON и XML. Кэшам нужно понимать, какие заголовки запроса влияют на выбор представления, чтобы не считать ответы взаимозаменяемыми.
Заголовок Vary появился как часть механизма управления таким кэшированием. Он описывает зависимость ответа от отдельных заголовков запроса и помогает общим кэшам разделять варианты одного ресурса.
Предположим, первый клиент отправил запрос с Accept: application/json, а сервер вернул JSON. Если ответ закэширован без Vary: Accept, кэш может считать URL единственным ключом и сохранить только этот вариант.
Когда следующий клиент запросит тот же ресурс с Accept: application/xml, кэш способен вернуть ранее сохранённый JSON. HTTP-статус может остаться успешным, поэтому проверка только статуса или данных приложения не обнаружит нарушение.
Интеграционная проверка должна пройти через тот компонент, который реально кэширует ответы: reverse proxy, CDN или другой общий кэш. Сначала нужно получить ресурс с одним значением Accept, затем запросить его с другим значением и проверить, что возвращено соответствующее представление.
Кроме тела ответа, следует проверить заголовок Vary: Accept у вариантов, выбор которых действительно зависит от Accept. Этот заголовок сообщает кэшу, что значение Accept входит в ключ варианта ответа.
Минимальная иллюстрация ожидаемого контракта:
Проверка только напрямую сервера может пройти даже при ошибке: приложение каждый раз выберет правильный формат, а проблема возникнет лишь на общем кэше. Поэтому это именно интеграционный сценарий с включённым кэширующим слоем.
Vary не требуется добавлять механически к каждому ответу. Если представление не зависит от Accept, лишние варианты кэширования могут снизить эффективность кэша без пользы. Также тест должен учитывать, что конкретная инфраструктура может вообще не использовать общий кэш; тогда риск нужно проверять на том уровне, где кэширование реально происходит.
API отчётов поддерживало JSON для мобильного клиента и XML для устаревшей системы. Тесты приложения отправляли запросы непосредственно в сервис и проходили: каждый запрос формировал правильное тело.
Рассматривались два варианта. Отключить кэширование для этого endpoint было проще, но это увеличивало нагрузку и ухудшало задержки. Проверять только Content-Type ответа было дешевле, но такой тест не обнаруживал повторную выдачу кэшированного представления.
Выбрали интеграционный тест через reverse proxy: запросы с разными Accept выполнялись последовательно, а затем сравнивались тела, Content-Type и Vary. В результате контракт закрепил разделение вариантов ответа, а кэш сохранил возможность ускорять чтение ресурса.
Vary: Accept в ответе, не выполняя два запроса через кэш?Нет. Наличие заголовка показывает намерение сервера, но не доказывает корректное поведение всей цепочки. Интеграционный тест должен убедиться, что кэш действительно различает варианты и не возвращает сохранённый ответ для другого Accept.
Content-Type может быть недостаточной?Кэш способен вернуть JSON с корректным для JSON Content-Type, даже если текущий клиент запрашивал XML. Заголовок будет согласован с ошибочно выбранным сохранённым представлением, поэтому нужно проверять последовательность запросов с разными значениями Accept и соответствие тела каждому запросу.
Vary все заголовки запроса?Нет. В Vary должны находиться только те заголовки, значения которых влияют на выбор представления. Избыточный список уменьшает долю попаданий в кэш и может увеличить нагрузку. Если на ответ влияют, например, язык или кодирование, их также нужно учитывать, но только при фактической зависимости ответа от этих параметров.