ترويسات HTTP (HTTP headers) هي أزواج مفتاح-قيمة تُرفق بكل طلب واستجابة HTTP، وتحمل معلومات عن الطلب نفسه — بمعزل عن المحتوى الفعلي المُرسَل — مثل هوية الجهة الطالبة، والصيغة التي تتوقع الحصول على البيانات بها، وكيفية التعامل مع هذه البيانات. وفي إدارة خلاصة المنتجات، تتيح الترويسات لمنصة الخلاصة أن تُثبت هويتها لدى واجهة API، وأن تحدد أنها ترسل أو تتوقع JSON بدلاً من XML، وأن تمرر تعليمات التخزين المؤقت أو الضغط، دون أن تتداخل أي من هذه المعلومات مع بيانات المنتجات الفعلية في متن الطلب.
لماذا تهمّ في إدارة خلاصة المنتجات
يعتمد كل اتصال آلي بين منصة الخلاصة وإحدى القنوات — Google Merchant Center أو Meta Catalog أو نظام ERP الخاص بالتاجر — على أداء الترويسات لدورها بشكل صحيح. فترويسة Authorization التي تحمل رمزاً غير صالح أو منتهي الصلاحية ستتسبب في فشل إرسال خلاصة سليمة التنسيق تماماً، كما أن غياب ترويسة Content-Type أو وجودها بشكل خاطئ قد يدفع القناة إلى تفسير حمولة JSON على أنها نص عادي أو العكس، مما يفسد عملية الرفع بصمت. وتتضمن الترويسات أيضاً منطق تحديد المعدل وإعادة المحاولة: إذ تعيد كثير من واجهات API ترويسات مثل Retry-After أو X-RateLimit-Remaining لتخبر منصة الخلاصة بعدد الطلبات التي يمكنها إرسالها قبل أن يتم تقييدها، وهو أمر مهم عند مزامنة عشرات الآلاف من SKU مع قناة تضع حداً أقصى للطلبات في الدقيقة. وغالباً ما يبدأ تشخيص فشل مزامنة الخلاصة بفحص الترويسات أولاً، لأن متن الطلب قد يبدو سليماً تماماً بينما تتسبب إحدى الترويسات بالرفض بهدوء.
آلية العمل
تُرسَل الترويسات كأسطر نصية عادية في أعلى طلب HTTP أو استجابته، منفصلة عن عنوان URL وعن المتن. وقد يتضمن طلب نموذجي إلى واجهة API للخلاصة الترويسة Authorization: Bearer <token> لإثبات هوية الجهة المتصلة، والترويسة Content-Type: application/json للإعلان عن صيغة البيانات المُرسَلة، والترويسة Accept: application/json لتحديد الصيغة المتوقع استلامها. وعلى عكس معامل الاستعلام أو معاملات URL الأخرى التي تظهر مباشرة في شريط العنوان، فإن الترويسات غير مرئية في عنوان URL نفسه، مما يجعلها المكان المناسب للمعلومات الحساسة مثل رموز المصادقة التي ينبغي ألا تظهر في سجل المتصفح أو سجلات الخادم. وتُضبط بعض الترويسات تلقائياً من العميل أو الخادم (مثل Date أو 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 أعلاه ليست سمة حقيقية في الخلاصة، لكنها توضح بيانات الترويسات الوصفية التي ترافق بيانات هذا العنصر في كل مرة يُرسَل فيها إلى إحدى القنوات عبر استدعاء API بدلاً من رفع ملف دفعة واحدة.
مفاهيم ذات صلة
تعمل الترويسات جنباً إلى جنب مع معاملات الاستعلام ومعاملات URL التي تنتقل مع الطلب أيضاً، ولكن بشكل منفصل عنها، والفارق الأساسي هو الظهور: فالترويسات لا تظهر في عنوان URL، ولهذا توضع فيها رموز المصادقة بدلاً من إلحاقها بالرابط. وتحدد هذه العناصر الثلاثة معاً ما تتلقاه واجهة API الخاصة بالقناة فعلياً، وأي خطأ في أحدها يُعدّ من أكثر أسباب فشل مزامنة الخلاصة بصمت شيوعاً.