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参数 直接显示在地址栏中的标头在 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实际接收到的内容，其中任何一个出错都是导致信息流同步静默失败的最常见原因之一。