Os cabeçalhos HTTP são os pares de chave-valor anexados a cada requisição e resposta HTTP que carregam informações sobre a própria requisição — separadas do conteúdo efetivamente enviado —, como quem está fazendo a solicitação, em que formato os dados são esperados e como eles devem ser tratados. Na gestão de feeds, são os cabeçalhos que permitem que uma plataforma de feeds se autentique em uma API, indique que está enviando ou esperando JSON em vez de XML e repasse instruções de cache ou compressão, tudo isso sem que nenhuma dessas informações polua os dados de produto no corpo da requisição.
Por que é importante para a gestão de feeds
Toda conexão automatizada entre uma plataforma de feeds e um canal — Google Merchant Center, Meta Catalog, o próprio ERP de um varejista — depende de os cabeçalhos funcionarem corretamente. Um cabeçalho Authorization com um token inválido ou expirado faz com que o envio de um feed, de resto perfeitamente formatado, falhe de imediato, e um cabeçalho Content-Type ausente ou incorreto pode levar um canal a interpretar um payload JSON como texto simples, ou vice-versa, corrompendo um upload silenciosamente. Os cabeçalhos também são onde ficam a limitação de taxa e a lógica de novas tentativas: muitas APIs retornam cabeçalhos como Retry-After ou X-RateLimit-Remaining para informar à plataforma de feeds quantas requisições ela ainda pode fazer antes de ser limitada, o que é importante ao sincronizar dezenas de milhares de SKUs com um canal que limita as requisições por minuto. Depurar uma sincronização de feed que falhou muitas vezes começa pela inspeção dos cabeçalhos, já que o corpo de uma requisição pode parecer perfeitamente correto enquanto um cabeçalho causa a rejeição sem alarde.
Como funciona
Os cabeçalhos são enviados como linhas de texto simples no início de uma requisição ou resposta HTTP, separados da URL e do corpo. Uma requisição típica a uma API de feeds pode incluir Authorization: Bearer <token> para comprovar a identidade de quem chama, Content-Type: application/json para declarar o formato dos dados enviados e Accept: application/json para especificar o formato esperado na resposta. Diferentemente de um parâmetro de consulta ou dos demais parâmetros de URL que aparecem diretamente na barra de endereço, os cabeçalhos são invisíveis na própria URL, o que os torna o lugar certo para informações sensíveis, como tokens de autenticação, que não devem aparecer no histórico do navegador nem nos logs do servidor. Alguns cabeçalhos são definidos automaticamente pelo cliente ou pelo servidor (como Date ou Content-Length), enquanto outros — especialmente os de autenticação e os cabeçalhos personalizados de rastreamento — são configurados explicitamente por quem desenvolve a integração.
Exemplo
<!-- 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>O bloco sync_request_headers acima não é um atributo real de feed, mas ilustra os metadados de cabeçalho que acompanham os dados desse item sempre que ele é enviado a um canal por meio de uma chamada de API, e não por upload de arquivo em massa.
Conceitos relacionados
Os cabeçalhos funcionam junto com — mas separadamente dos — parâmetros de consulta e parâmetros de URL que também acompanham uma requisição, e a principal diferença é a visibilidade: os cabeçalhos ficam fora da URL, e é por isso que os tokens de autenticação ficam neles, em vez de serem anexados a um link. Juntos, os três definem o que a API de um canal realmente recebe, e errar qualquer um deles é uma das causas mais comuns de falhas silenciosas na sincronização de feeds.
