Os cabeçalhos HTTP são pares de chave-valor anexados a cada solicitação e resposta HTTP que carregam informações sobre a própria solicitação — separadas do conteúdo enviado — como quem está fazendo a solicitação, em que formato os dados são esperados e como os dados devem ser tratados. No gerenciamento de feeds, os cabeçalhos permitem que uma plataforma de feeds se autentique em uma API, especifique que está enviando ou esperando JSON em vez de XML e transmita instruções de cache ou compressão, tudo isso sem que essas informações interfiram nos dados do produto no corpo da solicitação.

Por que isso é importante para o manejo da alimentação animal

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 do funcionamento correto dos cabeçalhos. Authorization Um cabeçalho contendo um token inválido ou expirado fará com que o envio de um feed, mesmo que perfeitamente formatado, falhe completamente, e resultará em um cabeçalho ausente ou incorreto. Content-Type O cabeçalho pode fazer com que um canal interprete erroneamente uma carga útil JSON como texto simples, ou vice-versa, corrompendo silenciosamente um upload. Os cabeçalhos também são onde reside a lógica de limitação de taxa e de repetição: muitas APIs retornam cabeçalhos como Retry-After or X-RateLimit-Remaining Para informar a uma plataforma de feeds quantas requisições ela pode fazer antes de ser limitada, é importante ao sincronizar dezenas de milhares de SKUs com um canal que limita as requisições por minuto. Depurar uma sincronização de feed com falha geralmente se resume a inspecionar os cabeçalhos primeiro, já que o corpo de uma requisição pode parecer perfeitamente correto enquanto um cabeçalho está silenciosamente causando a rejeição.

Como Funciona

Os cabeçalhos são enviados como linhas de texto simples no início de uma solicitação ou resposta HTTP, separadamente da URL e do corpo da requisição. Uma solicitação típica de API de feed pode incluir: Authorization: Bearer <token> Para comprovar a identidade de quem ligou, Content-Type: application/json declarar o formato dos dados que estão sendo enviados, e Accept: application/json para especificar o formato esperado de retorno. Ao contrário de um parâmetro de consulta ou o outro Parâmetros de URL Os cabeçalhos, que aparecem diretamente na barra de endereços, são invisíveis na própria URL, o que os torna o local ideal para informações sensíveis, como tokens de autenticação, que não devem aparecer no histórico do navegador ou nos registros do servidor. Alguns cabeçalhos são definidos automaticamente pelo cliente ou pelo servidor (como Date or Content-Length), enquanto outros — particularmente a autenticação e os cabeçalhos de rastreamento personalizados — 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 sync_request_headers O bloco acima não é um atributo real do feed, mas ilustra os metadados do cabeçalho que acompanham os dados deste item sempre que ele é enviado para um canal por meio de uma chamada de API, em vez de um upload em massa de arquivo.

Conceitos Relacionados

Os cabeçalhos funcionam em conjunto com os parâmetros de consulta e os parâmetros de URL , que também acompanham uma solicitação, mas separadamente. A principal diferença reside na visibilidade: os cabeçalhos não estão presentes na URL, razão pela qual os tokens de autenticação ficam lá em vez de serem anexados a um link. Juntos, os três definem o que a API de um canal realmente recebe, e a configuração incorreta de qualquer um deles é uma das causas mais comuns de falha silenciosa na sincronização do feed.