Заголовки HTTP

HTTP-заголовки — это пары «ключ-значение», добавляемые к каждому HTTP-запросу и ответу, которые содержат информацию о самом запросе — отдельно от фактического отправляемого содержимого — например, кто запрашивает, в каком формате ожидаются данные и как эти данные должны быть обработаны. В системах управления фидами заголовки позволяют платформе аутентифицироваться в API, указать, что она отправляет или ожидает JSON, а не XML, и передать инструкции по кэшированию или сжатию, при этом никакая из этой информации не засоряет фактические данные о продукте в теле запроса.

Почему это важно для управления кормлением

Любое автоматизированное соединение между платформой фидов и каналом — Google Merchant Center, Meta Catalog, собственной ERP-системой ритейлера — зависит от корректной работы заголовков. Authorization Заголовок, содержащий недействительный или просроченный токен, приведет к тому, что отправка ленты, в остальном идеально отформатированной, завершится неудачей, а отсутствующий или некорректный заголовок также может привести к ошибке. Content-Type Заголовки могут привести к тому, что канал неправильно интерпретирует полезную нагрузку JSON как обычный текст или наоборот, незаметно повреждая загружаемый файл. В заголовках также размещается логика ограничения скорости и повторных попыток: многие API возвращают заголовки, подобные этим. Retry-After or X-RateLimit-Remaining Это позволяет сообщить платформе фида, сколько еще запросов она может отправить, прежде чем будет ограничена скорость, что важно при синхронизации десятков тысяч SKU с каналом, который ограничивает количество запросов в минуту. Отладка неудачной синхронизации фида часто сводится к проверке заголовков, поскольку тело запроса может выглядеть совершенно корректно, в то время как заголовок незаметно вызывает отклонение.

Как это работает

Заголовки отправляются в виде строк обычного текста в начале HTTP-запроса или ответа, отдельно от URL-адреса и тела запроса. Типичный запрос к API ленты новостей может включать в себя следующее: Authorization: Bearer <token> для подтверждения личности звонившего, Content-Type: application/json указать формат отправляемых данных и Accept: application/json чтобы указать формат, ожидаемый в ответе. В отличие от параметр запроса или другой URL параметры Заголовки, которые отображаются непосредственно в адресной строке, невидимы в самом URL-адресе, что делает их идеальным местом для конфиденциальной информации, такой как токены аутентификации, которые не должны отображаться в истории браузера или журналах сервера. Некоторые заголовки устанавливаются автоматически клиентом или сервером (например, Date or 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 канала , и ошибка в любом из них является одной из наиболее распространенных причин незаметного сбоя синхронизации ленты.