Las cabeceras HTTP son los pares clave-valor que acompañan a cada solicitud y respuesta HTTP y que contienen información sobre la propia solicitud, independiente del contenido real que se envía: quién la hace, en qué formato espera los datos y cómo deben tratarse. En la gestión de feeds, las cabeceras son lo que permite a una plataforma de feeds autenticarse ante una API, indicar que envía o espera JSON en lugar de XML y transmitir instrucciones de caché o compresión, todo ello sin que esa información sature los datos de producto reales del cuerpo de la solicitud.
Por qué es importante para la gestión de feeds
Cada conexión automatizada entre una plataforma de feeds y un canal (Google Merchant Center, Meta Catalog, el propio ERP de un comerciante) depende de que las cabeceras funcionen correctamente. Una cabecera Authorization con un token no válido o caducado hará que falle por completo un envío de feed que, por lo demás, tiene un formato perfecto, y una cabecera Content-Type ausente o incorrecta puede hacer que un canal interprete una carga JSON como texto plano, o viceversa, corrompiendo una subida de forma silenciosa. Las cabeceras son también donde reside la lógica de limitación de frecuencia y de reintentos: muchas API devuelven cabeceras como Retry-After o X-RateLimit-Remaining para indicar a una plataforma de feeds cuántas solicitudes más puede hacer antes de ser limitada, algo importante al sincronizar decenas de miles de SKU con un canal que limita las solicitudes por minuto. Depurar una sincronización de feed fallida suele empezar por inspeccionar las cabeceras, ya que el cuerpo de una solicitud puede parecer perfectamente correcto mientras una cabecera provoca el rechazo sin hacer ruido.
Cómo funciona
Las cabeceras se envían como líneas de texto plano al principio de una solicitud o respuesta HTTP, separadas de la URL y del cuerpo. Una solicitud típica a la API de un feed puede incluir Authorization: Bearer <token> para demostrar la identidad de quien llama, Content-Type: application/json para declarar el formato de los datos enviados y Accept: application/json para especificar el formato esperado en la respuesta. A diferencia de un parámetro de consulta o de los demás parámetros de URL que aparecen directamente en la barra de direcciones, las cabeceras no son visibles en la propia URL, lo que las convierte en el lugar adecuado para información sensible como los tokens de autenticación, que no deberían aparecer en el historial del navegador ni en los registros del servidor. Algunas cabeceras las establece automáticamente el cliente o el servidor (como Date o Content-Length), mientras que otras, en particular las de autenticación y las de seguimiento personalizadas, las configura explícitamente quien desarrolla la integración.
Ejemplo
<!-- 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>El bloque sync_request_headers anterior no es un atributo de feed real, pero ilustra los metadatos de cabecera que acompañan a los datos de este artículo cada vez que se envían a un canal mediante una llamada a la API en lugar de una subida masiva de archivos.
Conceptos relacionados
Las cabeceras funcionan junto con (pero por separado de) los parámetros de consulta y los parámetros de URL que también viajan con una solicitud, con la diferencia clave de la visibilidad: las cabeceras quedan fuera de la URL, por lo que los tokens de autenticación se colocan ahí en lugar de añadirse a un enlace. En conjunto, los tres definen lo que realmente recibe la API de un canal, y equivocarse en cualquiera de ellos es una de las causas más habituales de que una sincronización de feed falle de forma silenciosa.
