Gli HTTP header sono le coppie chiave-valore allegate a ogni richiesta e risposta HTTP che trasportano informazioni sulla richiesta stessa, separate dal contenuto effettivamente inviato: ad esempio chi sta facendo la richiesta, in quale formato si aspetta i dati e come i dati devono essere gestiti. Nella gestione dei feed, gli header sono ciò che permette a una piattaforma di feed di autenticarsi presso un'API, di specificare che sta inviando o si aspetta JSON anziché XML e di trasmettere istruzioni di caching o compressione, il tutto senza che queste informazioni appesantiscano i dati di prodotto nel corpo della richiesta.
Perché sono importanti per la gestione dei feed
Ogni collegamento automatico tra una piattaforma di feed e un canale (Google Merchant Center, Meta Catalog, l'ERP di un retailer) dipende dal corretto funzionamento degli header. Un header Authorization con un token non valido o scaduto fa fallire del tutto l'invio di un feed altrimenti formattato alla perfezione, e un header Content-Type mancante o errato può portare un canale a interpretare un payload JSON come testo semplice, o viceversa, corrompendo silenziosamente un caricamento. Gli header sono anche il luogo in cui risiedono la logica di rate limiting e di retry: molte API restituiscono header come Retry-After o X-RateLimit-Remaining per indicare a una piattaforma di feed quante altre richieste può fare prima di essere limitata, un aspetto importante quando si sincronizzano decine di migliaia di SKU con un canale che pone un tetto alle richieste al minuto. Il debug di una sincronizzazione del feed non riuscita spesso si riduce a ispezionare per primi gli header, perché il corpo di una richiesta può sembrare perfettamente corretto mentre è un header a causarne silenziosamente il rifiuto.
Come funzionano
Gli header vengono inviati come righe di testo semplice in cima a una richiesta o risposta HTTP, separate dall'URL e dal corpo. Una tipica richiesta a un'API dei feed può includere Authorization: Bearer <token> per dimostrare l'identità del chiamante, Content-Type: application/json per dichiarare il formato dei dati inviati e Accept: application/json per specificare il formato atteso in risposta. A differenza di un query parameter o degli altri parametri URL che compaiono direttamente nella barra degli indirizzi, gli header non sono visibili nell'URL, il che li rende il posto giusto per informazioni sensibili come i token di autenticazione, che non dovrebbero comparire nella cronologia del browser o nei log del server. Alcuni header vengono impostati automaticamente dal client o dal server (come Date o Content-Length), mentre altri, in particolare quelli di autenticazione e di tracking personalizzato, vengono configurati esplicitamente da chi realizza l'integrazione.
Esempio
<!-- 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>Il blocco sync_request_headers qui sopra non è un vero attributo del feed, ma illustra i metadati degli header che accompagnano i dati di questo articolo ogni volta che vengono inviati a un canale tramite una chiamata API anziché con il caricamento massivo di un file.
Concetti correlati
Gli header funzionano insieme, ma separatamente, ai query parameter e ai parametri URL che viaggiano anch'essi con una richiesta; la differenza fondamentale è la visibilità: gli header restano fuori dall'URL, ed è per questo che i token di autenticazione si trovano lì invece di essere aggiunti a un link. Insieme, tutti e tre definiscono ciò che l'API di un canale riceve effettivamente, e sbagliarne anche uno solo è una delle cause più comuni di una sincronizzazione del feed che fallisce silenziosamente.
