HTTP STATUS 204 - لا محتوى: شرح وأفضل الممارسات

يتعرف معظم الأشخاص في المساحة الرقمية على رموز حالة HTTP المألوفة مثل 200 OK أو 404 غير موجودة ، ولكن بعضها لا تحصل على الكثير من الأضواء.

واحد من هؤلاء هو 204 لا محتوى.دعنا نلقي نظرة فاحصة على ما تعنيه هذه الحالة ، وكيف تعمل ، وعندما يكون ذلك مناسبًا للاستخدام.

ماذا يعني HTTP 204؟

تساعد رموز حالة HTTP الخوادم والمتصفحات على البقاء على نفس الصفحة من خلال إظهار ما حدث مع طلب.فئة 2xx من الرموز عادة ما تكون أكثر ما نقدره لأنها تظهر أن الطلب كان ناجحًا.

من بين هؤلاء ، 204 لا يوجد محتوى يحتل مكانًا فريدًا.ويؤكد أن الخادم قد تم التعامل معه بنجاح مع طلب العميل ولكن ليس لديه محتوى لإعادة إرساله.وبعبارة أخرى ، يخبر الخادم العميل "سار كل شيء على ما يرام ، ولكن لا يوجد شيء جديد لكي ترىه".

مزيد من فهم الاستجابة

تختلف حالة 204 عن الاستجابات الناجحة الأخرى لأنه لا يتضمن أي محتوى يتجاوز رؤوس HTTP.على الرغم من أن 200 OK قد تُرجع HTML أو JSON أو غيرها من أنواع الوسائط ، إلا أن 204 إرجاع فقط في قسم الرأس وتترك هيئة الاستجابة فارغة.

إليك مثال على شكل استجابة 204 على مستوى البروتوكول:

HTTP/1.1 204 No Content
Date: Mon, 09 Jun 2025 15:22:30 GMT

لا يوجد جسم بعد الرأس - لا علامة ، لا json ، لا رسالة.يمكن للعميل أن يفترض بأمان الإجراء المكتمل كما هو متوقع ، لكنه لا يحتاج إلى تحديث واجهة المستخدم أو إعادة تحميل أي محتوى.

يعد هذا تطبيقًا مفيدًا بشكل خاص في المواقف التي قدم فيها العميل بالفعل كل ما يحتاجه ويريد فقط تأكيدًا على أن عملية الخلفية (مثل استدعاء النموذج أو API) قد نجحت.

كيف يعمل HTTP 204

عندما يقوم العميل - مثل المتصفح أو تطبيق الهاتف المحمول أو البرنامج النصي - بطلب طلب ، فإنه يطلب من الخادم إجراء إجراء.قد يكون هذا أي شيء من تحديث إعدادات المستخدم أو حذف مورد أو التحقق من معلومات جديدة.

إليك ما يحدث عادة عند استخدام استجابة 204:

1. يرسل العميل طلب: يبدأ العميل طلبًا إلى الخادم.قد يكون هذا منشورًا لحفظ البيانات ، أو حذفًا لإزالة مورد ، أو الحصول على التحقق من التحديثات.
   
   
2. يعالج الخادم الطلب: يقوم الخادم بإجراء الإجراء المطلوب.قد يحفظ معلومات جديدة ، أو حذف عنصر ، أو التحقق من عدم حدوث أي تغييرات.
   
   
3. لا يوجد محتوى للعودة: إذا لم تكن هناك حاجة لإعادة إرسال جسم رسالة - لا توجد صفحة جديدة ، وليس بيانات محدثة - استجاب الخادم بحالة 204.
   
   
4. يتلقى العميل التأكيد: يرى العميل استجابة 204 وتفهم أن الطلب قد نجح ، ولكن لا يوجد شيء جديد لعرضه أو تحديثه.
   
   
5. لا يوجد تغيير في صفحة أو تغيير واجهة المستخدم: نظرًا لأن الاستجابة لا تحتوي على محتوى ، فإن العميل يحتفظ بالشاشة الحالية أو الواجهة دون تغيير ، مع الحفاظ على تجربة مستخدم سلسة.

لماذا قد ترغب في استخدام 204 حالة

على الرغم من أن 204 قد يبدو ضئيلًا ، إلا أنه يخدم غرضًا محددًا في التواصل عديمة الجنسية ، وخاصة في واجهات برمجة التطبيقات المريحة.إنه مثالي للتفاعلات الخفيفة الوزن حيث لا يوجد لدى الخادم أي شيء جديد للعودة ، لكن العميل لا يزال يحتاج إلى إقرار نهائي.

متى تستخدم رمز الحالة 204

إن معرفة الوقت المناسب لإرسال 204 لا استجابة لمحتوى ، ستساعد تفاعلات الموقع والتطبيق بسلاسة ، وتجنب إعادة تحميل الصفحة غير الضرورية ، وتحسين تجربة المستخدم بشكل عام.

الخلفية تنقذ في تطبيقات الويب

تنقذ العديد من تطبيقات الويب إدخال المستخدم تلقائيًا ، مثل عندما يقوم المستخدم بتغيير الإعدادات أو التفضيلات.بدلاً من إعادة تحميل الصفحة أو عرض رسالة تأكيد في كل مرة ، يرسل التطبيق التحديث بهدوء في الخلفية.تؤكد استجابة 204 التغيير الذي نجح فيه دون مقاطعة تدفق المستخدم.

مثال: تحفظ صفحة الإعدادات التغييرات بمجرد تبديل المستخدم:

fetch('/api/save-setting', {
  method: 'POST',
  body: JSON.stringify({ darkMode: true })
});

يستجيب الخادم بـ:

HTTP/1.1 204 No Content

لا تقوم الصفحة بتحديث أو عرض رسالة ، ولكن يتم حفظ التفضيل خلف الكواليس.

الاقتراع أو التحقق من التحديثات

بعض التطبيقات تحقق بشكل دوري من الخادم للحصول على معلومات جديدة باستخدام طلبات الخلفية.عندما لا تكون هناك بيانات جديدة ، تخبر استجابة 204 العميل أن كل شيء الحالي ، مما يمنع إرسال المحتوى غير الضروري.

مثال:

GET /api/notifications
→ 204 No Content

حذف الطلبات في واجهات برمجة التطبيقات

عندما تقوم واجهة برمجة التطبيقات بحذف مورد ، فغالبًا ما لا تحتاج إلى إرجاع أي محتوى.يشير رمز الحالة 204 إلى أن الحذف يعمل ، مع الحفاظ على الاستجابة خفيفة الوزن.

مثال:

DELETE /api/posts/123
→ 204 No Content

يعرف العميل أن المنشور تمت إزالته دون تلقي بيانات إضافية.

طلب أو تصحيح الطلبات مع عدم وجود بيانات إرجاع

لتحديث الموارد التي لا يحتاج العميل إلى أي بيانات أو تأكيد جديد يتجاوز النجاح ، يغلق 204 التفاعل بشكل نظيف.

مثال:

PATCH /api/user/profile
→ 204 No Content

يفترض العميل أن التحديث كان ناجحًا ولا يعيد تحميل العرض الحالي أو يغيره.

عندما لا تستخدم 204 لا محتوى

على الرغم من أن 204 لها مكانها ، إلا أن هناك حالات يمكن أن تسبب استخدامها في الارتباك أو كسر الوظائف المتوقعة:

عندما يتوقع العميل المحتوى

إذا كان العميل مصممًا لمعالجة أو عرض البيانات في الاستجابة - مثل HTML أو JSON أو حتى رسالة نجاح بسيطة - فإن 204 لن يسبب مشكلات لأنها لا توفر شيئًا إلى ما وراء الرؤوس.في هذه الحالات ، يكون 200 موافق مع هيئة الاستجابة عادةً خيارًا أفضل.

لإعادة توجيه أو تحديث واجهة المستخدم

إذا احتاج تطبيقك إلى تحديث الواجهة ، أو إظهار التعليقات للمستخدم ، أو إعادة التوجيه بعد الطلب ، فلن يساعد 204.رموز الحالة الأخرى مثل 200 أو 201 أو حتى أ 307 إعادة التوجيه قد يكون أكثر ملاءمة.

عند استخدامها مع بعض أنواع الطلبات

يمكن أن تتصرف بعض مكتبات ومستعرضات العملاء بشكل غير متوقع إذا تلقوا 204 بعد منشور أو طلب آخر لتغيير الدولة.إذا كانت العملية تثير منطقًا من جانب العميل بناءً على محتوى الاستجابة ، فقد يتسبب تخطي الجسم في حدوث أخطاء أو يجعل تصحيح الأخطاء أكثر صعوبة.

لمعالجة الأخطاء

204 يعني كل شيء على ما يرام.إذا حدث خطأ ما - مثل التحقق من صحة الفشل أو الإدخال المفقود أو مشكلة الخادم - لا ينبغي استخدام 204.ستكون الحالة من نطاق 4xx أو 5xx أكثر ملاءمة في هذه الحالات.

تعرف على المزيد: تحقق من أكواد خطأ HTTP نظرة عامة أو غوص أعمق مع 403 ممنوع دليل لفهم أفضل واستكشاف الأخطاء وإصلاحها.

باختصار ، يعمل 204 بشكل أفضل عندما لا يحتاج العميل إلى أي شيء جديد في المقابل - وكلا الجانبين واضحين في ذلك.إذا كانت هناك أي فرصة يتوقع العميل حمولة ، فإن استخدام استجابة مع المحتوى الفعلي يتجنب الغموض.

مقارنة 204 برموز حالة 2xx أخرى

تشير رموز حالة HTTP في نطاق 2xx جميعها إلى الطلبات الناجحة ، لكن كل منها يخدم غرضًا مختلفًا اعتمادًا على ما يحتاج العميل إلى معرفته أو القيام به بعد ذلك.يساعدك فهم هذه الاختلافات في اختيار الرمز المناسب لاستجابات الخادم الخاصة بك ويبقي التواصل بين العميل والخادم واضح وفعال.

تبرز حالة 204 لا يوجد محتوى لأنها تشير إلى النجاح دون إرجاع أي محتوى أو دفع تغييرات على جانب العميل.

كيف يختلف 204 عن رموز حالة 2xx الأخرى

• 200 OK: استجابة النجاح الأكثر شيوعًا ، تتضمن عادة المحتوى الذي يجب على العميل عرضه أو استخدامه.على سبيل المثال ، قم بتحميل صفحة ويب أو تلقي بيانات من واجهة برمجة التطبيقات.
  
• 201 تم إنشاؤه: يستخدم عند إنشاء مورد جديد ، مثل بعد الاشتراك أو إنشاء السجلات.غالبًا ما يتضمن تفاصيل حول المورد ، لكن هيئة الاستجابة اختيارية.
  
• 202 مقبولة: تعني أن الطلب قد تم استلامه وفهمه ، لكن المعالجة ستحدث لاحقًا.لا يوجد محتوى استجابة فوري ، شائع في الإجراءات غير المتزامنة.
  
• 204 لا محتوى: يؤكد النجاح مع عدم وجود محتوى للعودة.يخبر العميل لا حاجة إلى تحديث الشاشة أو إعادة تحميل الصفحة - مثالية لعمليات الخلفية الصامتة مثل حفظ أو حذف.
  
• 205 إعادة تعيين المحتوى: لا يرسل أي محتوى ولكن يرشد العميل لإعادة تعيين واجهة المستخدم أو مسحه ، مثل مسح حقول الإدخال بعد إرسال نموذج.

اعتبارات كبار المسئولين الاقتصاديين

عندما يتعلق الأمر بمحركات البحث ، يمكن أن تؤثر كيفية استجابة الخادم الخاص بك على ما إذا كانت صفحاتك تظهر في نتائج البحث.في حين أن رمز حالة المحتوى 204 لا يتم استخدامه في الغالب للتفاعلات من وراء الكواليس ، من المهم فهم آثاره على الفهرسة والرؤية.يمكن أن يؤدي استخدامه في السياق الخاطئ إلى منع صفحاتك عن غير قصد من التعرف على محركات البحث أو إرباك الروبوتات الزاحفة.

204 لا يتم فهرسة الردود

نظرًا لأن حالة 204 تشير إلى أن الخادم قام بنجاح بمعالجة الطلب ولكن ليس لديه محتوى لإظهاره ، فإن محركات البحث تعامل هذه الاستجابات على أنها فارغة.لن تتم إضافة الصفحات التي تعود إلى 204 إلى فهارس محرك البحث ، مما يعني أنها لن تظهر في نتائج البحث.

تجنب 204 للحصول على صفحات الويب العامة

إذا كانت الصفحة التي تهدف للمستخدمين لعرض - مثل صفحة المنتج أو منشور المدونة أو الصفحة الرئيسية - تستجيب بـ 204 ، فإن محركات البحث ستعتبرها فارغة.يمكن أن يؤدي ذلك إلى إسقاط الصفحة من نتائج البحث تمامًا ، مما يحد من رؤية موقعك وحركة المرور المحتملة.

استخدم 204 فقط لطلبات API أو الخلفية

إن حالة 204 مخصصة أفضل لمكالمات API ، أو حفظ الخلفية ، أو العمليات الأخرى التي لا تقدم محتوى مرئيًا.بالنسبة للصفحات والموارد التي تحتاج إلى فهرسة وعرض ، استخدم رموز النجاح القياسية مثل 200 مع تضمين المحتوى الكامل.

راقب استجابات 204 عرضية

في بعض الأحيان تتسبب أخطاء التكوين أو الأخطاء في إرجاع الصفحات 204 عن طريق الخطأ.تحقق بانتظام من موقعك للحصول على 204 استجابات غير متوقعة على عناوين URL المهمة لمنع فقدان حركة مرور محرك البحث.

مثال: إذا كانت الصفحة/حول الصفحة تُرجع 204 بدلاً من 200 مع المحتوى ، فسوف تخطي Google فهرسته.

فوائد الأداء

على الرغم من أن رمز حالة المحتوى 204 نفسه لا يزيد من تسريع موقعك عن طريق السحر ، فإن استخدامه بعناية يمكن أن يقلل من عمليات نقل البيانات غير الضرورية والمعالجة.يؤدي ذلك إلى تجربة أصغر للمستخدمين ، وخاصة على الأجهزة ذات الاتصالات الأبطأ أو الموارد المحدودة.

أحجام استجابة أصغر

نظرًا لأن استجابة 204 لا تحتوي على أي شخص ، فإنها ترسل فقط الرؤوس إلى العميل.هذا يعني انخفاض انتقال البيانات عبر الشبكة مقارنة بصفحة HTML كاملة أو استجابة JSON.توفر الاستجابات الأصغر عرضًا للنطاق الترددي ويمكن أن تقلل من أوقات التحميل ، مما يهم المستخدمين على شبكات الهاتف المحمول أو سرعات الإنترنت أبطأ.

تفاعلات أسرع

من خلال تأكيد النجاح دون إرسال محتوى إضافي ، تتيح 204 ردود على التطبيقات معالجة عمليات الخلفية بصمت وبسرعة.على سبيل المثال ، لن تقاطع الإعدادات الموفرة التلقائية أو التأكيد على واجهة المستخدم ، مما يتيح للتطبيق أن يشعر أكثر استجابة وسلاسة.

تقليل معالجة من جانب العميل

عندما يتلقى المتصفح أو التطبيق 204 ، فإنه لا يحتاج إلى تحليل أو تقديم أي محتوى ، مما يقلل من عبء العمل على العميل.يحرر هذا الموارد للمهام الأخرى ، وتحسين الأداء الكلي وتجربة المستخدم ، وخاصة على الأجهزة ذات الطاقة المنخفضة.

إدارة أفضل للموارد

باستخدام 204 يساعد الخوادم والشبكات بشكل استراتيجي على تجنب إرسال بيانات غير ضرورية.يمكن أن يؤدي ذلك إلى خفض تحميل الخادم وتقليل حركة المرور ، مما يسهل توسيع نطاق التطبيق عند التعامل مع العديد من المستخدمين أو طلبات الخلفية المتكررة.

أخطاء شائعة لتجنب

يحتوي رمز المحتوى 204 على قواعد وسلوكيات محددة يجب اتباعها لتجنب مشاكل غير متوقعة للمستخدمين أو كسر وظائف الموقع/التطبيق.يساعد معرفة هذه المزالق الشائعة في التأكد من أن التنفيذ يبقى على نحو سلس ويمكن التنبؤ به ، سواء بالنسبة للمستخدمين والأنظمة الداعمة.

إرجاع جسم استجابة مع 204

تنص مواصفات HTTP بوضوح على أن استجابة 204 يجب ألا تتضمن هيئة استجابة.هذا يعني أنه لا ينبغي أن يصاحب HTML أو JSON أو أي محتوى آخر رمز الحالة هذا.يمكن أن يخلط بين الجسم المتصفحات والعملاء ، والتي لا تتوقع أي محتوى.قد يتجاهل بعض العملاء الجسم ، في حين أن البعض الآخر قد يتصرف بشكل غير متوقع.

مثال خطأ:
يستجيب الخادم لطلب الخلفية مع 204 حالة ولكنه يتضمن بطريق الخطأ رسالة JSON صغيرة مثل {"الحالة": "OK"}.هذا يمكن أن يتسبب في فشل العميل في معالجة الاستجابة بشكل صحيح.

أفضل الممارسات:
تأكد دائمًا من أن الخادم الخاص بك يرسل الرؤوس فقط مع استجابة 204 - لا توجد رسائل هيئة.

باستخدام 204 للصفحات التي تهدف إلى عرض المحتوى

إذا قام المستخدم بزيارة عنوان URL يتوقع صفحة ويب ، فإن الاستجابة بـ 204 ستظهر صفحة فارغة تمامًا - لا توجد أخطاء ، لا محتوى ، مجرد مساحة فارغة.هذا يربك المستخدمين ، ويؤدي إلى ضعف تجربة المستخدم ، ويؤدي إلى تخطي محركات البحث فهرسة الصفحة.

مثال خطأ:
تُرجع صفحة "من نحن" عن طريق الخطأ 204 بدلاً من 200 مع محتوى HTML ، لذلك يرى الزوار شاشة فارغة ومحركات البحث لا تفهرس الصفحة.

أفضل الممارسات:
استخدم 200 OK لأي صفحات تهدف إلى عرض المحتوى.الاحتياطي 204 لمكالمات API الخلفية أو الإجراءات التي لا تتطلب ملاحظات واضحة.

باستخدام 204 لتجاوز معالجة الأخطاء

في بعض الأحيان ، قد يرسل المطورون استجابة 204 حتى إذا لم تنجح العملية ، لتجنب التعامل مع حالات الخطأ.هذا يخفي المشكلة من العميل ويمكن أن يؤدي إلى الارتباك أو فقدان البيانات.

مثال خطأ:
يتلقى واجهة برمجة التطبيقات مدخلات غير صالحة ولكنها تستجيب بـ 204 ، مما يجعل العميل يعتقد أن الطلب نجح عندما فشل بالفعل.

أفضل الممارسات:
استخدم رموز الخطأ المناسبة مثل 400 طلب سيء أو 422 كيان غير قابل للمعالجة لمشكلات التحقق من الصحة ، و 500 خطأ خادم داخلي لمشاكل الخادم.أرسل 204 فقط عندما تنجح العملية حقًا ولا يوجد محتوى للعودة.

تجاهل التأثير على منطق العميل

نظرًا لأن 204 ردود لا تتضمن هيئة ، فإن تطبيقات العميل تتوقع أن تقوم البيانات بتحديث واجهة المستخدم أو تتصرف بشكل غير متوقع إذا تلقى 204 دون التعامل معها بشكل صحيح.

مثال خطأ:
يتوقع البرنامج النصي في الواجهة الأمامية بيانات JSON بعد عملية حفظ ، لكن الخادم يرجع 204. إذا لم يتحقق البرنامج النصي عن 204 ، فقد يفشل أو يظهر بيانات قديمة.

أفضل الممارسات:
تصميم رمز من جانب العميل للتعامل مع 204 ردود برشاقة-معالجةها كإشارات نجاح بدون بيانات-وتحديث واجهة المستخدم وفقًا لذلك.

خلط 204 مع إعادة التوجيه أو الرؤوس التخزين المؤقت بشكل غير صحيح

يجب أن تكون رموز استجابة HTTP متسقة مع رؤوس أخرى مثل إعادة التوجيه أو عناصر التحكم في ذاكرة التخزين المؤقت.على سبيل المثال ، يمكن أن يؤدي إرسال 204 جنبا إلى جنب مع حالة إعادة توجيه أو تعليمات ذاكرة التخزين المؤقت المتضاربة إلى سلوك غير محدد.

مثال خطأ:
إرجاع 204 مع رأس موقع لإعادة توجيه العميل ، وهو أمر غير صالح.تتطلب إعادة التوجيه رموز حالة 3xx.

أفضل الممارسات:
الحفاظ على 204 ردود بسيطة وخالية من الرؤوس المتضاربة.إذا كنت بحاجة إلى إعادة التوجيه ، فاستخدم رمز الحالة المناسبة مثل 301 أو 302.

تغليف

HTTP Status 204 هو رمز صغير ممتع يوفر طريقة نظيفة وفعالة للإشارة إلى النجاح دون إرسال المحتوى مرة أخرى.إنه يبقي التطبيقات مستجيبة من خلال تأكيد مهام الخلفية بصمت وكفاءة.

يستخدم بشكل مناسب ، فهو يساعد موقعك أو التطبيق على البقاء سريعًا وسلسًا.فقط تجنب استخدامه على الصفحات التي تحتاج إلى إظهار المحتوى أو فهرستها بواسطة محركات البحث.