Nagłówki HTTP to pary klucz-wartość dołączane do każdego żądania i odpowiedzi HTTP, które niosą informacje o samym żądaniu – niezależnie od faktycznie przesyłanej treści – na przykład o tym, kto pyta, w jakim formacie oczekuje danych i jak dane mają być obsłużone. W zarządzaniu feedami to właśnie nagłówki pozwalają platformie feedowej uwierzytelnić się w API, wskazać, że wysyła lub oczekuje JSON zamiast XML, oraz przekazać instrukcje dotyczące cache’owania lub kompresji – a wszystko to bez zaśmiecania faktycznych danych produktowych w treści żądania.
Dlaczego to ważne w zarządzaniu feedami
Każde zautomatyzowane połączenie między platformą feedową a kanałem – Google Merchant Center, Meta Catalog czy własnym ERP sprzedawcy – zależy od tego, czy nagłówki działają poprawnie. Nagłówek Authorization z nieprawidłowym lub wygasłym tokenem sprawi, że przesłanie feedu, poza tym idealnie sformatowanego, zakończy się niepowodzeniem, a brakujący lub błędny nagłówek Content-Type może spowodować, że kanał zinterpretuje dane JSON jako zwykły tekst (lub odwrotnie), po cichu psując przesyłkę. W nagłówkach mieszka też logika limitów i ponownych prób: wiele API zwraca nagłówki takie jak Retry-After czy X-RateLimit-Remaining, aby poinformować platformę feedową, ile jeszcze żądań może wysłać, zanim zostanie spowolniona – co ma znaczenie przy synchronizacji dziesiątek tysięcy SKU z kanałem ograniczającym liczbę żądań na minutę. Debugowanie nieudanej synchronizacji feedu często sprowadza się do sprawdzenia w pierwszej kolejności nagłówków, ponieważ treść żądania może wyglądać całkowicie poprawnie, podczas gdy to nagłówek po cichu powoduje odrzucenie.
Jak to działa
Nagłówki są wysyłane jako linie zwykłego tekstu na początku żądania lub odpowiedzi HTTP, oddzielnie od adresu URL i treści. Typowe żądanie do API feedu może zawierać Authorization: Bearer <token>, aby potwierdzić tożsamość wywołującego, Content-Type: application/json, aby zadeklarować format wysyłanych danych, oraz Accept: application/json, aby określić oczekiwany format odpowiedzi. W przeciwieństwie do parametru zapytania czy innych parametrów URL, które pojawiają się bezpośrednio w pasku adresu, nagłówki są niewidoczne w samym URL, dzięki czemu stanowią właściwe miejsce na poufne informacje, takie jak tokeny uwierzytelniające, które nie powinny trafiać do historii przeglądarki ani logów serwera. Niektóre nagłówki są ustawiane automatycznie przez klienta lub serwer (np. Date czy Content-Length), a inne – zwłaszcza nagłówki uwierzytelniające i niestandardowe nagłówki śledzące – konfiguruje bezpośrednio osoba budująca integrację.
Przykład
<!-- 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>Powyższy blok sync_request_headers nie jest prawdziwym atrybutem feedu, ale ilustruje metadane nagłówków, które towarzyszą danym tego produktu za każdym razem, gdy są wysyłane do kanału przez wywołanie API, a nie przez zbiorcze przesłanie pliku.
Powiązane pojęcia
Nagłówki działają obok – ale niezależnie od – parametrów zapytania i parametrów URL, które również podróżują razem z żądaniem. Kluczowa różnica to widoczność: nagłówki nie trafiają do adresu URL, dlatego tokeny uwierzytelniające umieszcza się w nich, a nie dołącza do linku. Razem te trzy elementy określają, co faktycznie otrzymuje API kanału, a błąd w którymkolwiek z nich to jedna z najczęstszych przyczyn cichych niepowodzeń synchronizacji feedu.
