Сервис ограничивает частоту запросов и отвечает 429. Какой элемент HTTP-контракта должен проверить интеграционный тест, чтобы клиент мог корректно выбрать момент повтора?
Интеграционный тест должен проверить согласованный контракт заголовка Retry-After в ответе 429 Too Many Requests. Он сообщает клиенту, через какой интервал или после какого момента допустимо повторить запрос, поэтому проверка только статус-кода не гарантирует корректное поведение клиента.
Одного статус-кода недостаточно, чтобы передать клиенту практическую инструкцию по повтору операции. Для временных ограничений HTTP предусматривает поле Retry-After, которое используется совместно с ответами вроде 429 и может задавать задержку в секундах либо абсолютную дату.
Такой подход отделяет факт отказа от рекомендации по восстановлению. Клиенту не приходится угадывать задержку или немедленно повторять запрос, создавая дополнительную нагрузку.
Если тест проверяет только наличие 429, он может пропустить отсутствие Retry-After, неправильный формат его значения или несогласованную единицу измерения. В результате клиент способен повторить запрос слишком рано, получить новый отказ и усилить нагрузку на уже перегруженный сервис.
Особенно опасна ситуация, когда разные компоненты трактуют значение по-разному: один ожидает число секунд, а другой передаёт или разбирает дату. Это приводит к преждевременным повторам, чрезмерным задержкам или отказу от повторения.
В контракте нужно явно зафиксировать, должен ли ответ 429 содержать Retry-After, какой вариант значения разрешён и как клиент его применяет. Интеграционная проверка должна подтвердить как минимум наличие заголовка при предусмотренном контрактом сценарии и корректность его значения.
При использовании задержки в секундах тест проверяет, что значение является неотрицательным целым числом и находится в допустимом диапазоне. При использовании абсолютной даты необходимо учитывать часы клиента и сервера: сравнение должно выполняться с допустимым временным допуском либо через контролируемое время.
Retry-After не означает, что запрос гарантированно будет принят после указанного момента. Это рекомендация сервера, поэтому клиенту всё равно нужны ограничение числа попыток, экспоненциальная задержка, случайное рассеивание задержек и обработка окончательного отказа.
Не следует механически требовать этот заголовок для любого 429, если он не входит в контракт конкретного API: HTTP допускает разные варианты поведения сервера. Тест должен проверять именно договорённость между данным клиентом и сервисом, а не неподтверждённое предположение.
Платёжный сервис временно ограничивал обращения к провайдеру и возвращал 429. Клиент при отсутствии специальной инструкции повторял запрос через фиксированную секунду, из-за чего несколько экземпляров сервиса синхронно создавали новый всплеск нагрузки.
Рассматривались три варианта. Полностью отказаться от повторов было безопасно для нагрузки, но приводило к лишним пользовательским ошибкам. Задать фиксированную задержку было просто, однако она не учитывала реальное состояние лимита. Использовать Retry-After с локальным ограничением попыток лучше соответствовало поведению сервера, но потребовало проверки формата заголовка и обработки некорректных значений.
Выбрали третий вариант: сервисный контракт сделал заголовок обязательным для данного типа 429, а клиент применял его как минимальную задержку, добавляя случайное рассеивание и ограничение общего времени повтора. Интеграционный тест проверял статус, заголовок и допустимость его значения; повторные всплески после исчерпания лимита исчезли.
Нет, это зависит от применяемого контракта. Если API не объявил заголовок обязательным, клиент должен иметь безопасное поведение по умолчанию, а тест не должен требовать его исключительно на основании статус-кода. Если же клиент полагается на него для корректного восстановления, обязательность нужно закрепить в контракте сервиса и проверять интеграционно.
Она не выявляет неправильную семантику значения. Например, число может быть отрицательным, слишком большим, передаваться не в тех единицах или дата может быть некорректной для разбора. Тест должен проверять формат, диапазон и соответствие согласованным правилам интерпретации.
Значение задаёт рекомендацию, а не гарантию успешного результата. Несколько клиентов могут получить одинаковую задержку и снова обратиться одновременно, а ограничение может сохраниться дольше указанного срока. Поэтому поверх заголовка нужны случайное рассеивание, максимальное число попыток, общий тайм-аут и корректное завершение с ошибкой.