HTTP-заголовки — это пары «ключ — значение», которые прикрепляются к каждому HTTP-запросу и ответу и передают информацию о самом запросе отдельно от отправляемого содержимого: кто запрашивает, в каком формате ожидаются данные и как их следует обрабатывать. В управлении фидами именно заголовки позволяют платформе фидов аутентифицироваться в API, указать, что она отправляет или ожидает JSON, а не XML, и передать инструкции по кешированию или сжатию — и всё это без загромождения самих товарных данных в теле запроса.
Почему это важно для управления фидами
Каждое автоматическое подключение между платформой фидов и каналом — Google Merchant Center, Meta Catalog, собственной ERP ритейлера — зависит от того, правильно ли работают заголовки. Заголовок Authorization с недействительным или просроченным токеном приведёт к полному отказу при отправке фида, даже если сам фид отформатирован безупречно, а отсутствующий или неверный заголовок Content-Type может заставить канал интерпретировать JSON-данные как обычный текст или наоборот, незаметно повредив загрузку. В заголовках также живёт логика ограничения частоты запросов и повторных попыток: многие API возвращают заголовки вроде Retry-After или X-RateLimit-Remaining, сообщая платформе фидов, сколько ещё запросов она может отправить до наступления ограничения, — это важно при синхронизации десятков тысяч SKU с каналом, который ограничивает число запросов в минуту. Отладка неудачной синхронизации фида часто начинается именно с проверки заголовков, ведь тело запроса может выглядеть совершенно правильным, тогда как отклонение незаметно вызывает какой-то заголовок.
Как это работает
Заголовки отправляются в виде строк простого текста в начале HTTP-запроса или ответа, отдельно от URL и тела. Типичный запрос к API фидов может содержать Authorization: Bearer <token> для подтверждения личности вызывающей стороны, Content-Type: application/json для объявления формата отправляемых данных и Accept: application/json для указания ожидаемого формата ответа. В отличие от параметра запроса и других параметров URL, которые видны прямо в адресной строке, заголовки в самом URL не видны, поэтому именно там уместно передавать конфиденциальную информацию, например токены аутентификации, которые не должны попадать в историю браузера или серверные логи. Некоторые заголовки устанавливаются клиентом или сервером автоматически (например, Date или Content-Length), а другие — особенно заголовки аутентификации и пользовательские заголовки отслеживания — явно настраивает тот, кто строит интеграцию.
Пример
<!-- Representative HTTP request headers sent when a feed platform
pushes a product update to a channel's API -->
<item>
<g:id>SKU-40217</g:id>
<title>Ceramic Plant Pot - 8 inch, Terracotta</title>
<g:price>18.50 USD</g:price>
<sync_request_headers>
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json
</sync_request_headers>
</item>Блок sync_request_headers выше — не настоящий атрибут фида, а иллюстрация метаданных заголовков, которые сопровождают данные этого товара каждый раз, когда он передаётся в канал через вызов API, а не загрузкой файла целиком.
Связанные понятия
Заголовки работают вместе с параметрами запроса и параметрами URL, которые тоже передаются с запросом, но отдельно от них. Ключевое различие — видимость: заголовки не попадают в URL, поэтому токены аутентификации передаются в них, а не добавляются к ссылке. Вместе эти три элемента определяют, что фактически получает API канала, и ошибка в любом из них — одна из самых частых причин незаметного сбоя синхронизации фида.
