HTTP-headers zijn de sleutel-waardeparen die aan elk HTTP-verzoek en -antwoord worden meegegeven en informatie over het verzoek zelf bevatten, los van de eigenlijke inhoud die wordt verstuurd, zoals wie de vraag stelt, in welk formaat de data verwacht wordt en hoe de data moet worden verwerkt. In feedbeheer zorgen headers ervoor dat een feedplatform zich bij een API kan authenticeren, kan aangeven dat het JSON verstuurt of verwacht in plaats van XML, en instructies voor caching of compressie kan meesturen, zonder dat die informatie de eigenlijke productdata in de body van het verzoek vervuilt.
Waarom het belangrijk is voor feedbeheer
Elke geautomatiseerde verbinding tussen een feedplatform en een kanaal, of dat nu Google Merchant Center, Meta Catalog of het eigen ERP van een retailer is, is ervan afhankelijk dat headers hun werk goed doen. Een Authorization-header met een ongeldig of verlopen token laat een verder perfect opgemaakte feedinzending direct mislukken, en een ontbrekende of onjuiste Content-Type-header kan ertoe leiden dat een kanaal een JSON-payload als platte tekst interpreteert, of andersom, waardoor een upload ongemerkt beschadigd raakt. Headers zijn ook de plek waar rate limiting en retrylogica zitten: veel API's sturen headers als Retry-After of X-RateLimit-Remaining terug om een feedplatform te laten weten hoeveel verzoeken het nog kan doen voordat het wordt afgeremd. Dat is belangrijk als je tienduizenden SKU's synchroniseert met een kanaal dat het aantal verzoeken per minuut beperkt. Het debuggen van een mislukte feedsynchronisatie komt vaak neer op eerst de headers bekijken, omdat de body van een verzoek er volkomen correct uit kan zien terwijl een header stilletjes de afwijzing veroorzaakt.
Hoe het werkt
Headers worden verstuurd als regels platte tekst bovenaan een HTTP-verzoek of -antwoord, los van de URL en de body. Een typisch verzoek aan een feed-API kan Authorization: Bearer <token> bevatten om de identiteit van de aanroeper te bewijzen, Content-Type: application/json om het formaat van de verstuurde data aan te geven en Accept: application/json om het verwachte antwoordformaat op te geven. Anders dan een queryparameter of de andere URL-parameters die direct in de adresbalk verschijnen, zijn headers onzichtbaar in de URL zelf. Daardoor zijn ze de juiste plek voor gevoelige informatie zoals authenticatietokens, die niet in de browsergeschiedenis of serverlogs horen te verschijnen. Sommige headers worden automatisch door de client of server ingesteld (zoals Date of Content-Length), terwijl andere, met name authenticatieheaders en eigen trackingheaders, expliciet worden geconfigureerd door degene die de integratie bouwt.
Voorbeeld
<!-- 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>Het blok sync_request_headers hierboven is geen echt feedattribuut, maar illustreert de headermetadata die met de data van dit artikel meegaat telkens wanneer het via een API-aanroep naar een kanaal wordt gepusht in plaats van via een bulkupload van een bestand.
Gerelateerde begrippen
Headers werken samen met, maar los van, de queryparameters en URL-parameters die ook met een verzoek meereizen. Het belangrijkste verschil is zichtbaarheid: headers blijven buiten de URL, en daarom staan authenticatietokens daar en niet achter een link geplakt. Samen bepalen ze wat de API van een kanaal daadwerkelijk ontvangt, en als een van de drie niet klopt, is dat een van de meest voorkomende oorzaken van een feedsynchronisatie die ongemerkt mislukt.
