HTTP-Header sind die Schlüssel-Wert-Paare, die jeder HTTP-Anfrage und -Antwort beigefügt sind und Informationen über die Anfrage selbst transportieren – getrennt vom eigentlich übermittelten Inhalt –, etwa wer anfragt, in welchem Format die Daten erwartet werden und wie sie verarbeitet werden sollen. Im Feed-Management ermöglichen Header einer Feed-Plattform, sich gegenüber einer API zu authentifizieren, anzugeben, dass sie JSON statt XML sendet oder erwartet, und Anweisungen zu Caching oder Komprimierung mitzugeben – ohne dass diese Informationen die eigentlichen Produktdaten im Request-Body überfrachten.
Warum sie für das Feed-Management wichtig sind
Jede automatisierte Verbindung zwischen einer Feed-Plattform und einem Kanal – Google Merchant Center, Meta-Katalog, das eigene ERP eines Händlers – hängt davon ab, dass Header ihre Aufgabe korrekt erfüllen. Ein Authorization-Header mit einem ungültigen oder abgelaufenen Token lässt eine ansonsten einwandfrei formatierte Feed-Übermittlung komplett scheitern, und ein fehlender oder falscher Content-Type-Header kann dazu führen, dass ein Kanal eine JSON-Nutzlast als reinen Text interpretiert oder umgekehrt – und einen Upload unbemerkt beschädigt. In Headern stecken auch Rate-Limiting und Wiederholungslogik: Viele APIs liefern Header wie Retry-After oder X-RateLimit-Remaining, die einer Feed-Plattform mitteilen, wie viele Anfragen sie noch stellen kann, bevor sie gedrosselt wird. Das ist entscheidend, wenn Zehntausende SKUs mit einem Kanal synchronisiert werden, der die Anfragen pro Minute begrenzt. Die Fehlersuche bei einer fehlgeschlagenen Feed-Synchronisierung beginnt deshalb oft mit den Headern, denn der Body einer Anfrage kann völlig korrekt aussehen, während ein Header unbemerkt die Ablehnung verursacht.
Wie sie funktionieren
Header werden als Klartextzeilen am Anfang einer HTTP-Anfrage oder -Antwort übertragen, getrennt von der URL und dem Body. Eine typische Anfrage an eine Feed-API kann Authorization: Bearer <token> enthalten, um die Identität des Aufrufers nachzuweisen, Content-Type: application/json, um das Format der gesendeten Daten anzugeben, und Accept: application/json, um das erwartete Antwortformat festzulegen. Anders als ein Query-Parameter oder andere URL-Parameter, die direkt in der Adressleiste erscheinen, sind Header in der URL selbst unsichtbar. Deshalb sind sie der richtige Ort für sensible Informationen wie Authentifizierungstokens, die nicht im Browserverlauf oder in Server-Logs auftauchen sollen. Manche Header werden automatisch vom Client oder Server gesetzt (etwa Date oder Content-Length), während andere – insbesondere Authentifizierungs- und eigene Tracking-Header – explizit von demjenigen konfiguriert werden, der die Integration entwickelt.
Beispiel
<!-- 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>Der obige Block sync_request_headers ist kein echtes Feed-Attribut, veranschaulicht aber die Header-Metadaten, die die Daten dieses Artikels jedes Mal begleiten, wenn sie per API-Aufruf statt per Massen-Upload einer Datei an einen Kanal übertragen werden.
Verwandte Begriffe
Header arbeiten neben – aber getrennt von – den Query-Parametern und URL-Parametern, die ebenfalls mit einer Anfrage übertragen werden. Der entscheidende Unterschied ist die Sichtbarkeit: Header bleiben aus der URL heraus, weshalb Authentifizierungstokens dort liegen und nicht an einen Link angehängt werden. Zusammen bestimmen alle drei, was die API eines Kanals tatsächlich empfängt, und ein Fehler bei einem davon gehört zu den häufigsten Gründen, warum eine Feed-Synchronisierung unbemerkt scheitert.
