Accept / Content-Type

التفاوض على المحتوى (Content Negotiation) Accept / Content-Type

آلية تسمح للعميل والخادم بالاتفاق على صيغة تمثيل المورد المتبادل — عبر ترويسات Accept وContent-Type.

المورد الواحد قد تتوفر له عدة تمثيلات (JSON، XML، CSV...)؛ Content Negotiation هي الآلية التي يختار بها الخادم التمثيل الأنسب للعميل. العميل يرسل Accept ليخبر الخادم بالصيغ التي يقبلها وترتيب أفضليتها (باستخدام معامل الجودة q)، والخادم يرد بـ Content-Type ليخبر العميل بصيغة الجسم الفعلي الذي أرسله.

إن لم يستطع الخادم تلبية أي صيغة من قائمة Accept، يجب عليه حسب RFC 9110 أن يردّ بـ 406 Not Acceptable بدل إرسال صيغة غير مطلوبة. معظم REST APIs الحديثة تدعم JSON فقط وتتجاهل هذا التعقيد عمليًا، لكن فهمه ضروري عند بناء واجهة تخدم عدة صيغ فعلًا.

الصياغة

// الطلب
Accept: application/json, application/xml;q=0.5

// الاستجابة
Content-Type: application/json

📄 مثال

GET /api/articles/42 HTTP/1.1
Accept: application/json

// الاستجابة
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{ "id": 42, "title": "..." }

أهم النقاط

العنصر	الوظيفة
Accept	يرسله العميل — الصيغ التي يقبلها وترتيب أفضليتها
Content-Type	يرسله الطرفان — صيغة الجسم الفعلي المرفق بالرسالة
406 Not Acceptable	رد الخادم إن لم يستطع تلبية أي صيغة من Accept

💡 نصائح عملية

إن كانت واجهتك تدعم JSON فقط، لا داعٍ لتطبيق تفاوض معقّد — فقط تحقق من Content-Type في الطلبات الواردة وارفض غير JSON بوضوح
استخدم q في Accept عند بناء عميل يتعامل مع عدة APIs بصيغ مختلفة

⚠️ أخطاء شائعة

الخلط بين Accept (ما يريده العميل) وContent-Type (ما تحتويه الرسالة فعليًا) — غالبًا سبب أخطاء 415/406
تجاهل ترويسة Content-Type الواردة والافتراض دائمًا أن الجسم JSON دون تحقق

خصائص ذات صلة

GET طريقة GET Location ترويسة Location

🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار REST-API الكامل بالعربي.

📚 للتعمق التقني الكامل بالإنجليزية: MDN Web Docs