HTTP-Header

HTTP-Header sind Schlüssel-Wert-Paare, die jeder HTTP-Anfrage und -Antwort beigefügt werden und Informationen über die Anfrage selbst enthalten – getrennt vom eigentlichen Inhalt. Dazu gehören beispielsweise der Absender, das erwartete Datenformat und die Art der Datenverarbeitung. Im Feed-Management ermöglichen Header einer Feed-Plattform die Authentifizierung gegenüber einer API, die Angabe, dass JSON anstelle von XML gesendet oder erwartet wird, sowie die Übermittlung von Anweisungen zum Caching oder zur Komprimierung. All dies geschieht, ohne dass diese Informationen die eigentlichen Produktdaten im Anfragetext beeinträchtigen.

Warum es für das Futtermanagement wichtig ist

Jede automatisierte Verbindung zwischen einer Feed-Plattform und einem Kanal – Google Merchant Center, Meta Catalog, dem ERP-System eines Einzelhändlers – hängt davon ab, dass die Header korrekt funktionieren. Authorization Ein Header mit einem ungültigen oder abgelaufenen Token führt dazu, dass eine ansonsten korrekt formatierte Feed-Übermittlung sofort fehlschlägt, und ein fehlender oder falscher Content-Type Header können dazu führen, dass ein Kanal eine JSON-Nutzlast fälschlicherweise als Klartext interpretiert oder umgekehrt, wodurch ein Upload unbemerkt beschädigt wird. Header enthalten auch die Logik für Ratenbegrenzung und Wiederholungsversuche: Viele APIs geben Header wie beispielsweise „json::property“ zurück. Retry-After or X-RateLimit-Remaining Um einer Feed-Plattform mitzuteilen, wie viele Anfragen sie noch stellen darf, bevor sie gedrosselt wird, ist es wichtig, Zehntausende von SKUs mit einem Kanal zu synchronisieren, der die Anzahl der Anfragen pro Minute begrenzt. Die Fehlersuche bei einer fehlgeschlagenen Feed-Synchronisierung erfordert oft zunächst die Überprüfung der Header, da der Anfragetext korrekt erscheinen kann, während ein Header unbemerkt die Ablehnung verursacht.

Funktionsweise

Header werden als Klartextzeilen am Anfang einer HTTP-Anfrage oder -Antwort gesendet, getrennt von der URL und dem Body. Eine typische Feed-API-Anfrage könnte Folgendes beinhalten: Authorization: Bearer <token> um die Identität des Anrufers zu beweisen, Content-Type: application/json um das Format der zu sendenden Daten zu deklarieren, und Accept: application/json um das erwartete Rückgabeformat anzugeben. Im Gegensatz zu einem Abfrageparameter oder die andere URL-Parameter Header, die direkt in der Adressleiste erscheinen, sind in der URL selbst unsichtbar. Daher eignen sie sich ideal für sensible Informationen wie Authentifizierungstoken, die nicht im Browserverlauf oder in Serverprotokollen auftauchen sollten. Einige Header werden automatisch vom Client oder Server gesetzt (z. B. `@URL`). Date or Content-Length), während andere – insbesondere Authentifizierungs- und benutzerdefinierte Tracking-Header – explizit von demjenigen konfiguriert werden, der die Integration erstellt.

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>

Das sync_request_headers Der obige Block ist kein echtes Feed-Attribut, sondern veranschaulicht die Header-Metadaten, die die Daten dieses Elements jedes Mal begleiten, wenn sie über einen API-Aufruf und nicht über einen Massen-Datei-Upload an einen Kanal übertragen werden.

Verwandte konzepte

Header funktionieren neben – aber unabhängig von – den Abfrageparametern und URL-Parametern , die ebenfalls mit einer Anfrage übertragen werden. Der Hauptunterschied liegt in der Sichtbarkeit: Header sind nicht Teil der URL, weshalb Authentifizierungstoken dort gespeichert und nicht an einen Link angehängt werden. Zusammen definieren alle drei, was die API eines Kanals tatsächlich empfängt. Ein Fehler bei einem dieser Parameter ist eine der häufigsten Ursachen für einen unbemerkten Fehlschlag der Feed-Synchronisierung.