HTTP標頭

HTTP 頭部是附加到每個 HTTP 請求和回應的鍵值對，它攜帶關於請求本身的資訊——這些資訊獨立於實際發送的內容——例如請求者是誰、他們期望的資料格式以及資料的處理方式。在資訊流管理中，頭部資訊使資訊流平台能夠向 API 進行身份驗證、指定發送或期望的資料格式（例如 JSON 而非 XML），並傳遞快取或壓縮指令，所有這些資訊都不會幹擾請求正文中的實際產品資料。

為什麼這對飼料管理很重要

資訊流平台與通路（例如 Google Merchant Center、Meta Catalog 或零售商本身的 ERP 系統）之間的所有自動化連接都依賴頭部資訊的正確運作。 Authorization 如果請求頭包含無效或過期的令牌，即使格式完全正確的 Feed 提交也會直接失敗；此外，缺失或不正確的請求頭也會導致失敗。 Content-Type 頭部資訊可能導致通道將 JSON 負載誤解為純文本，反之亦然，從而悄無聲息地破壞上傳。速率限制和重試邏輯也存在於頭部資訊中：許多 API 都會傳回類似這樣的頭部資訊。 Retry-After or X-RateLimit-Remaining 這可以告訴資訊流平台在被限制之前還能發出多少次請求，這在將數萬個 SKU 同步到每分鐘請求數有限制的管道時至關重要。偵錯訊息流同步失敗的問題通常首先要檢查請求頭，因為請求體可能看起來完全正確，但某個請求頭卻悄悄地導致了請求被拒絕。

運作原理

請求頭以純文字行的形式傳送在 HTTP 請求或回應的頂部，與 URL 和請求體分開。一個典型的 Feed API 請求可能包含以下內容。 Authorization: Bearer <token> 為了證明來電者的身份， Content-Type: application/json 聲明所發送資料的格式，以及 Accept: application/json 指定預期回傳的格式。與……不同 查詢參數 或其他 網址參數 直接顯示在網址列中的標頭在 URL 本身是不可見的，因此它們是存放敏感資訊（例如身份驗證令牌）的理想位置，這些資訊不應出現在瀏覽器歷史記錄或伺服器日誌中。某些標頭由客戶端或伺服器自動設定（例如）。 Date or Content-Length），而其他（特別是身份驗證和自訂追蹤標頭）則由建置整合的人員明確配置。

例

<!-- 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>

这 sync_request_headers 上面的區塊並不是真正的 feed 屬性，但它說明了每次透過 API 呼叫而不是批次檔案上傳將此項目資料推送到頻道時，都會附帶的標頭元資料。

相關概念

請求頭與查詢參數和URL 參數並行工作，但彼此獨立，它們也隨請求一起傳遞。主要區別在於可見性：請求頭不包含在 URL 中，因此身份驗證令牌位於請求頭中，而不是附加到連結上。這三者共同定義了頻道API實際接收到的內容，其中任何一個出錯都是導致訊息流同步靜默失敗的最常見原因之一。