HTTP-headers

HTTP-headers zijn sleutel-waardeparen die aan elk HTTP-verzoek en -antwoord worden toegevoegd en informatie bevatten over het verzoek zelf – los van de daadwerkelijke inhoud die wordt verzonden – zoals wie de aanvraag doet, in welk formaat de gegevens worden verwacht en hoe de gegevens moeten worden verwerkt. In feedmanagement stellen headers een feedplatform in staat zich te authenticeren bij een API, aan te geven dat het JSON in plaats van XML verzendt of verwacht, en instructies voor caching of compressie door te geven, zonder dat deze informatie de daadwerkelijke productgegevens in de aanvraagbody onoverzichtelijk maakt.

Waarom dit belangrijk is voor voermanagement

Elke geautomatiseerde verbinding tussen een feedplatform en een kanaal – Google Merchant Center, Meta Catalog, het eigen ERP-systeem van een retailer – is afhankelijk van de correcte werking van de headers. Authorization Een header met een ongeldig of verlopen token zorgt ervoor dat een verder perfect opgemaakte feedinzending volledig mislukt, en een ontbrekende of onjuiste token kan eveneens problemen veroorzaken. Content-Type Een header kan ervoor zorgen dat een kanaal een JSON-payload verkeerd interpreteert als platte tekst, of andersom, waardoor een upload stilletjes wordt beschadigd. Headers bevatten ook logica voor rate-limiting en herhalingen: veel API's retourneren headers zoals Retry-After or X-RateLimit-Remaining Om een ​​feedplatform te laten weten hoeveel verzoeken het nog kan doen voordat de snelheid wordt beperkt, is belangrijk bij het synchroniseren van tienduizenden SKU's met een kanaal dat het aantal verzoeken per minuut beperkt. Het debuggen van een mislukte feedsynchronisatie komt vaak neer op het eerst controleren van de headers, omdat de inhoud van een verzoek er perfect correct uit kan zien, terwijl een header stilletjes de afwijzing veroorzaakt.

Hoe het werkt

Headers worden als platte tekstregels bovenaan een HTTP-verzoek of -antwoord verzonden, los van de URL en de body. Een typisch API-verzoek voor een feed zou bijvoorbeeld het volgende kunnen bevatten: Authorization: Bearer <token> om de identiteit van de beller te bewijzen, Content-Type: application/json om het formaat van de te verzenden gegevens te specificeren, en Accept: application/json om het verwachte retourformaat te specificeren. In tegenstelling tot een queryparameter of de andere URL-parameters In tegenstelling tot headers die direct in de adresbalk verschijnen, zijn deze onzichtbaar in de URL zelf. Dit maakt ze de ideale plek voor gevoelige informatie, zoals authenticatietokens, die niet in de browsergeschiedenis of serverlogboeken mogen verschijnen. Sommige headers worden automatisch ingesteld door de client of server (zoals <header>). Date or Content-Length), terwijl andere — met name authenticatie en aangepaste 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>

De sync_request_headers Het bovenstaande blok is geen echt feedkenmerk, maar het illustreert de headermetadata die bij de gegevens van dit item wordt meegestuurd telkens wanneer deze via een API-aanroep naar een kanaal worden verzonden, in plaats van via een bulkbestandupload.

Verwante concepten

Headers werken samen met, maar los van, de queryparameters en URL-parameters die ook met een verzoek worden meegestuurd. Het belangrijkste verschil zit hem in de zichtbaarheid: headers blijven buiten de URL, vandaar dat authenticatietokens daar staan ​​in plaats van aan een link te worden toegevoegd. Samen bepalen deze drie wat de API van een kanaal daadwerkelijk ontvangt, en een fout in een van deze elementen is een van de meest voorkomende oorzaken van een stille mislukking van de feedsynchronisatie.