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

1. 1xx إعلامية

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

• 100 متابعة: تلقى الخادم رؤوس الطلب ويجب على العميل المتابعة لإرسال نص الطلب.
• 101 تبديل البروتوكولات: طلب الطالب من الخادم تبديل البروتوكولات ووافق الخادم على القيام بذلك.

2.2xx النجاح

تشير رموز الحالة هذه إلى أنه تم استلام طلب العميل وفهمه وقبوله بنجاح.

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

3. إعادة توجيه 3xx

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

• تم نقل 301 نهائيًا: تم نقل المورد المطلوب بشكل دائم إلى عنوان URL جديد.
• تم العثور على 302: المورد المطلوب موجود مؤقتًا تحت عنوان URL مختلف.
• 304 غير معدل: يشير إلى أن المورد لم يتم تعديله منذ الإصدار المحدد بواسطة رؤوس الطلب.

4. خطأ العميل 4xx

رموز الحالة هذه مخصصة للمواقف التي يبدو أن العميل قد أخطأ فيها.

• 400 طلب سيئ: لا يمكن للخادم معالجة الطلب بسبب بناء جملة غير صالح أو إدخال غير صحيح.

  • مثال: إرسال JSON مشوه في نص الطلب.
  • الاستخدام: يُستخدم عندما يكون الطلب نفسه مشوهًا أو يحتوي على معلمات غير صالحة.

• 401 غير مصرح به: يتطلب الطلب مصادقة المستخدم.

  • مثال: محاولة الوصول إلى نقطة نهاية API محمية دون تقديم بيانات اعتماد صالحة.
  • الاستخدام: يُستخدم عندما تكون المصادقة مطلوبة ولم يتم تقديمها أو تكون غير صالحة.

• 403 محظور: الخادم يفهم الطلب لكنه يرفض السماح به.

  • مثال: يحاول مستخدم الوصول إلى ميزات المشرف فقط.
  • الاستخدام: يُستخدم عندما تتم مصادقة المستخدم ولكن ليس لديه إذن للعملية المطلوبة.

• 404 لم يتم العثور عليه: تعذر العثور على المورد المطلوب على الخادم.

  • مثال: محاولة استرداد ملف تعريف مستخدم محذوف.
  • الاستخدام: يُستخدم عندما لا يكون المورد المطلوب موجودًا.

• 405 الطريقة غير مسموح بها: الطريقة المحددة في الطلب غير مسموح بها للمورد المحدد بواسطة URI للطلب.

  • مثال: إرسال طلب POST إلى نقطة نهاية تقبل فقط طلبات GET.

• 409 تعارض: لا يمكن معالجة الطلب بسبب تعارض مع الحالة الحالية للمورد.

  • مثال: محاولة إنشاء مستخدم ببريد إلكتروني موجود بالفعل في النظام.
  • الاستخدام: يُستخدم عندما يكون هناك تعارض مع الحالة الحالية للمورد، مثل الإدخالات المكررة.

• 422 كيان غير قابل للمعالجة: يفهم الخادم نوع المحتوى وصياغة الطلب، ولكن لا يمكنه معالجة التعليمات المضمنة.

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

• 429 طلبات كثيرة جدًا: أرسل المستخدم عددًا كبيرًا جدًا من الطلبات في فترة زمنية معينة ("تحديد المعدل").

  • مثال: تطبيق تحديد معدل واجهة برمجة التطبيقات (API) لمنع إساءة الاستخدام.

5. خطأ في خادم 5xx

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

• 500 خطأ داخلي في الخادم: رسالة خطأ عامة تشير إلى أن الخادم واجه حالة غير متوقعة تمنعه ​​من تلبية الطلب.

  • مثال: حدث استثناء غير معالج في التعليمات البرمجية من جانب الخادم.

• 501 لم يتم تنفيذه: لا يدعم الخادم الوظيفة المطلوبة لتلبية الطلب.

  • مثال: استخدام طريقة HTTP جديدة لا يتعرف عليها الخادم.

• 502 بوابة سيئة: تلقى الخادم، أثناء عمله كبوابة أو وكيل، استجابة غير صالحة من الخادم الرئيسي.

  • مثال: لا يمكن لخادم وكيل عكسي الاتصال بالخادم الأصلي.

• 503 الخدمة غير متاحة: الخادم غير قادر حاليًا على التعامل مع الطلب بسبب التحميل الزائد المؤقت أو الصيانة.

  • مثال: يخضع الخادم لصيانة مجدولة أو يواجه حركة مرور عالية.

• 504 Gateway Timeout: الخادم، أثناء عمله كبوابة أو وكيل، لم يتلق استجابة في الوقت المناسب من الخادم الرئيسي.

  • مثال: تحدث مهلة أثناء انتظار استجابة من واجهة برمجة تطبيقات تابعة لجهة خارجية.

أفضل الممارسات لاستخدام رموز حالة HTTP

1. كن محددًا: استخدم رمز الحالة الأكثر تحديدًا الذي ينطبق على الموقف. وهذا يساعد العملاء على فهم ما حدث بالضبط وكيفية الرد.

2. الاستخدام المتسق : حافظ على الاتساق في كيفية استخدام رموز الحالة عبر واجهة برمجة التطبيقات الخاصة بك. وهذا يسهل على المطورين العمل مع واجهة برمجة التطبيقات (API) الخاصة بك.

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

4. الاعتبارات الأمنية: كن حذرًا بشأن الكشف عن الكثير من المعلومات في الاستجابات للأخطاء، خاصة بالنسبة لأخطاء 4xx و5xx. تجنب الكشف عن تفاصيل حساسة حول بنية النظام الخاص بك أو تنفيذه.

5. التوثيق : قم بتوثيق رموز الحالة التي تستخدمها واجهة برمجة التطبيقات الخاصة بك بوضوح وتحت أي ظروف. وهذا يساعد عملاء واجهة برمجة التطبيقات (API) على فهم كيفية تفسير الاستجابات المختلفة والتعامل معها.

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