HEAD

طريقة HEAD HEAD

HEAD تتصرف مثل GET لكنها تعيد الترويسات فقط دون جسم الاستجابة — مفيدة لفحص وجود مورد أو حجمه دون تحميله.

حسب RFC 9110، الخادم يجب أن يستجيب لـ HEAD بنفس الترويسات التي كان سيعيدها مع GET لنفس الرابط، لكن دون إرسال جسم الرسالة. هذا يسمح للعميل بالتحقّق من وجود مورد، حجمه (Content-Length)، أو تاريخ آخر تعديل (Last-Modified) دون استهلاك النطاق الترددي لتحميل المحتوى كاملًا.

مثل GET، فهي آمنة (Safe) وعديمة الأثر التراكمي (Idempotent). تُستخدم غالبًا في أدوات فحص الروابط، والتحقق من صلاحية ذاكرة تخزين مؤقت قبل تحميل المورد فعليًا.

الصياغة

HEAD /resource/:id

📄 مثال

HEAD /api/files/report.pdf HTTP/1.1

// الاستجابة — بلا جسم
HTTP/1.1 200 OK
Content-Length: 245678
Content-Type: application/pdf
Last-Modified: Mon, 20 Jul 2026 10:00:00 GMT

أهم النقاط

العنصر	الوظيفة
آمنة وعديمة الأثر التراكمي	نفس خصائص GET تمامًا
بلا جسم استجابة	الترويسات فقط، حتى لو كان المورد موجودًا وكاملًا
ترويسات مطابقة لـ GET	Content-Length وContent-Type وغيرها كما لو نُفِّذ GET فعليًا

💡 نصائح عملية

استخدمها للتحقق من وجود ملف كبير أو حجمه قبل تحميله فعليًا عبر GET
مفيدة أيضًا لفحص صلاحية رابط دون استهلاك بيانات الجهاز

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

توقّع جسم استجابة من HEAD في كود العميل — سيبقى فارغًا دائمًا بحسب المواصفة
عدم دعم HEAD في تطبيقات Express المخصَّصة رغم أن أطر العمل الحديثة تولّدها تلقائيًا من معالج GET

خصائص ذات صلة

GET طريقة GET OPTIONS طريقة OPTIONS

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

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