ما هو كود الحالة 405: طريقة غير مسموح بها؟ خطأ الأداة غير المناسبة

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

هذا هو الوضع الدقيق الذي يعبر عنه أحد رموز خطأ HTTP الأكثر تحديدًا وفائدة: 405 Method Not Allowed.

على عكس الخطأ الأكثر عمومية 404 Not Found (الذي يقول "لا يمكنني العثور على ما تبحث عنه") أو 400 Bad Request (الذي يقول "لا أفهم ما تقوله")، فإن خطأ 405 دقيق بشكل لا يصدق. إنه يقول: "لقد وجدت المورد الذي تبحث عنه، ولكنك تستخدم طريقة HTTP خاطئة للتفاعل معه."

إنها طريقة الخادم ليخبرك: "أنا أعرف ما هو /api/users، ولكن لا يمكنك حذفه (DELETE). حاول استخدام GET بدلاً من ذلك."

إذا كنت مطورًا تعمل مع واجهات برمجة تطبيقات RESTful، فإن فهم رمز حالة 405 أمر بالغ الأهمية لبناء واستهلاك واجهات برمجة التطبيقات بشكل صحيح.

في منشور المدونة المفصل هذا، سنستكشف كل ما تحتاج لمعرفته حول حالة 405 Method Not Allowed، بدءًا مما تعنيه، ولماذا تحدث، والسيناريوهات الشائعة، وكيفية إصلاحها، وأفضل الممارسات للتعامل معها بسلاسة.

زر

الآن، دعنا نستكشف الغرض والآليات والآثار العملية لرمز حالة HTTP 405 Method Not Allowed.

المشكلة: طرق HTTP وتصميم RESTful

لفهم 405، نحتاج إلى مراجعة سريعة لكيفية عمل واجهات برمجة تطبيقات RESTful. في تصميم RESTful، يمكن أن يتصرف نفس عنوان URL بشكل مختلف اعتمادًا على طريقة HTTP (الفعل) التي تستخدمها:

• GET /api/users - استرداد قائمة المستخدمين
• POST /api/users - إنشاء مستخدم جديد
• PUT /api/users/123 - تحديث المستخدم 123 (استبدال كامل)
• PATCH /api/users/123 - تحديث جزئي للمستخدم 123
• DELETE /api/users/123 - حذف المستخدم 123

يحدث خطأ 405 عندما تحاول استخدام طريقة لم يقم الخادم بتنفيذها لنقطة النهاية المحددة هذه. على سبيل المثال، محاولة POST إلى /api/users/123 (التي تدعم عادةً GET، PUT، PATCH، DELETE فقط) من المرجح أن تُرجع 405.

ماذا يعني HTTP 405 Method Not Allowed بالفعل؟

يشير رمز الحالة 405 Method Not Allowed إلى أن الخادم يعرف أن المورد المستهدف (عنوان URL الذي طلبته) موجود، ولكنه لا يدعم طريقة HTTP المستخدمة في الطلب.

هناك شرط حاسم لاستجابة 405 الصحيحة: يجب أن تتضمن رأس Allow الذي يسرد طرق HTTP التي هي مدعومة للمورد المطلوب.

تبدو استجابة 405 الصحيحة كالتالي:

HTTP/1.1 405 Method Not AllowedAllow: GET, HEAD, OPTIONSContent-Type: application/json
{
  "error": "Method Not Allowed",
  "message": "POST method is not supported for this endpoint."
}

دعنا نفصل المكون الرئيسي:

• Allow: GET, HEAD, OPTIONS: هذا هو الجزء الأكثر أهمية. يخبر هذا الرأس العميل بالضبط ما هي الطرق المسموح بها. إنه مثل الخادم يقول: "لا يمكنك استخدام مطرقة هنا، ولكن يمكنك استخدام هذه الأدوات الثلاث بدلاً من ذلك."

ببساطة، أرسل العميل طريقة HTTP صالحة مثل GET، POST، PUT، DELETE، وما إلى ذلك، ولكن الخادم لا يسمح بهذه الطريقة المعينة على عنوان URL أو نقطة النهاية المطلوبة.لماذا يحدث خطأ 405؟

يحدث خطأ 405 عندما لا تكون الطريقة المستخدمة في طلب HTTP مسموحًا بها للمورد. تشمل الأسباب الشائعة ما يلي:

• استدعاء GET على نقطة نهاية تدعم POST فقط.
• استخدام PUT حيث يدعم DELETE فقط.
• إرسال طلبات OPTIONS إلى موارد لا تسمح بذلك.
• تكوين خاطئ لتوجيه الخادم أو معالجات طرق HTTP.
• استخدام غير صحيح لواجهة برمجة تطبيقات REST أو وثائق قديمة.

يساعد فهم السبب الجذري في إصلاح المشكلة بكفاءة.

لماذا تُرجع الخوادم 405 بدلاً من 404؟

قد تتساءل لماذا لا تُرجع ببساطة 404 Not Found؟

حسنًا، 404 تعني أن المورد لم يتم العثور عليه على الإطلاق، ولكن 405 تعني أن المورد موجود، ولكن ليس بهذه الطريقة.

هذا التمييز مهم للمطورين لأنه يخبرك بما يلي:

• أنت في المكان الصحيح.
• أنت تستخدم الأداة الخاطئة فقط.

كيف يعمل: مثال ملموس

دعنا نتخيل نقطة نهاية API للقراءة فقط توفر معلومات المنتج.

الطلب الصحيح:

GET /api/products/123 HTTP/1.1Host: api.example.com

استجابة الخادم: 200 OK مع بيانات المنتج.

الطلب غير الصحيح:

يحاول العميل عن طريق الخطأ تحديث المنتج باستخدام PUT:

PUT /api/products/123 HTTP/1.1Host: api.example.comContent-Type: application/json
{"name": "اسم منتج جديد"}

استجابة الخادم 405:

HTTP/1.1 405 Method Not AllowedAllow: GET, HEADContent-Type: application/json
{
  "error": "Method Not Allowed",
  "message": "طريقة PUT غير مدعومة لهذا المورد."
}

يخبر الرأس Allow: GET, HEAD العميل بوضوح أن هذه نقطة نهاية للقراءة فقط. يعرف العميل الآن بالضبط ما حدث خطأ وكيفية إصلاحه.

لماذا يعتبر رأس Allow مهمًا جدًا؟

يحول رأس Allow الخطأ 405 من خطأ محبط إلى محادثة مفيدة. بدونه، سيُترك العميل في حيرة:

• مع رأس Allow: "لا يمكنني استخدام PUT هنا، ولكن يمكنني استخدام GET أو HEAD."
• بدون رأس Allow: "لا يمكنني استخدام PUT هنا. ¯\_(ツ)_/¯ حظًا سعيدًا في معرفة ما يمكنك فعله!"

لهذا السبب، تفرض مواصفات HTTP على الخوادم تضمين رأس Allow في استجابات 405. هذا ما يجعل الرمز مفيدًا حقًا بدلاً من أن يكون محبطًا فقط.

كيف تبدو استجابة 405؟

تستجيب الخوادم بحالة 405 بالإضافة إلى رأس Allow الذي يشير إلى طرق HTTP المسموح بها. يوجه RFC 7231 (مواصفات HTTP/1.1) بأنه عندما يتم إرسال رمز حالة 405، يجب على الخادم تضمين رأس Allow يسرد طرق HTTP المسموح بها لذلك المورد.

مثال على الاستجابة:

textHTTP/1.1 405 Method Not Allowed Allow: GET, HEAD, OPTIONS Content-Type: text/html
<html> <body> <h1>405 الطريقة غير مسموح بها</h1> <p>الطريقة المطلوبة POST غير مدعومة لهذا المورد.</p> </body> </html>

رأس Allow هو المفتاح لأنه يخبر العميل بالطرق المقبولة، مما يتيح إجراء التصحيحات.

وبهذه الطريقة، يعرف العملاء ما هي الطرق المدعومة ويمكنهم تعديل طلباتهم وفقًا لذلك.

السيناريوهات الشائعة التي تؤدي إلى أخطاء 405

1. نقاط النهاية للقراءة فقط

كما في مثالنا أعلاه، بعض الموارد هي للقراءة فقط عن قصد. يمكنك استردادها باستخدام GET، ولكن لا يمكنك تعديلها باستخدام PUT أو PATCH أو DELETE.

2. طريقة غير صحيحة للإجراء

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

• استخدام GET لإنشاء مورد (يجب أن يكون POST)
• استخدام POST لتحديث مورد (يجب أن يكون PUT أو PATCH)
• استخدام DELETE على عنوان URL لمجموعة مثل /api/users (يجب أن يكون على مورد محدد مثل /api/users/123)

3. عدم وجود تطبيق للطريقة

قد يكون مصمم API ببساطة لم يقم بتطبيق طريقة معينة لنقطة نهاية. على سبيل المثال، قد تدعم نقطة نهاية GET و POST ولكن ليس PUT أو DELETE.

4. جدران حماية تطبيقات الويب (WAFs) وقواعد الأمان

في بعض الأحيان، تقوم تكوينات الأمان بحظر طرق معينة عن قصد. على سبيل المثال، قد يحظر WAF طرق PUT و PATCH و DELETE على مسارات معينة لأسباب أمنية، مما يؤدي إلى إرجاع 405.

405 مقابل أخطاء 4xx الأخرى: معرفة الفرق

من المهم تمييز 405 عن رموز أخطاء العميل الأخرى.

• 405 Method Not Allowed مقابل 404 Not Found:

405 تعني "عنوان URL هذا موجود، ولكن ليس لهذه الطريقة."

404 تعني "عنوان URL هذا غير موجود لأي طريقة."

• 405 Method Not Allowed مقابل 501 Not Implemented:

405 تعني "أنا أعرف ما تريد فعله، ولكنني لن أسمح لك بفعله لهذا المورد المحدد." (خطأ العميل)

501 تعني "لا أعرف كيف أتعامل مع طريقة HTTP هذه على الإطلاق، لأي مورد." (خطأ الخادم)

• 405 Method Not Allowed مقابل 403 Forbidden:

405 تعني "هذه العملية غير متاحة لأي شخص." (قيود الطريقة)

403 تعني "هذه العملية متاحة، ولكن ليس لك بصلاحياتك الحالية." (قيود التفويض)

السيناريوهات الشائعة التي يظهر فيها 405

• واجهات برمجة تطبيقات RESTful: محاولة PUT إلى نقطة نهاية تدعم GET أو POST فقط.
• نماذج الويب: إرسال نموذج بطريقة GET إلى نقطة نهاية تتوقع POST.
• مسارات غير مهيأة بشكل صحيح: مسارات الخادم لا تتعامل مع طرق معينة بشكل صحيح.
• مشاكل البرمجيات الوسيطة: برامج الأمان التي تحظر أو تقوم بتصفية طرق محددة.
• الموارد الثابتة: طلب POST على صورة ثابتة أو عنوان URL لملف.

كيف يجب على العملاء التعامل مع 405 Method Not Allowed

عندما يتلقى العملاء استجابة 405، يجب عليهم:

• التحقق من رأس Allow لتحديد طرق HTTP المدعومة.
• تعديل الطلب لاستخدام طريقة مسموح بها.
• إعادة محاولة الطلب وفقًا لذلك.
• التعامل مع الأخطاء بسلاسة في واجهات المستخدم أو سير العمل.
• إبلاغ المستخدمين بالإجراءات غير المدعومة بوضوح.

كيف يمكن للمطورين إصلاح أخطاء 405

• مراجعة توجيه الخادم وتكوينه: التأكد من أن المسارات تتعامل مع جميع طرق HTTP المتوقعة.
• التحقق من وثائق API: التحقق من الاستخدام الصحيح لطريقة HTTP.
• تطبيق معالجات الطرق: تعريف معالجات لجميع الطرق المسموح بها بشكل صريح.
• الاستجابة برؤوس Allow الصحيحة: تحسين قابلية استخدام العميل.
• التحقق من طلبات العميل: اكتشاف استخدام الطريقة غير الصحيحة مبكرًا في تطبيقات العميل الخاصة بك.
• تسجيل أخطاء 405: لمراقبة وإصلاح المشكلات المتكررة.

أمثلة على طرق HTTP والاستخدام المسموح به

يؤدي عدم التطابق بين قدرات الطريقة والمورد إلى حدوث خطأ 405.

اختبار استجابات 405 باستخدام Apidog

يعد اختبار أن واجهة برمجة التطبيقات الخاصة بك تُرجع 405 بشكل صحيح للطرق غير المدعومة علامة مميزة لتطوير واجهة برمجة تطبيقات قوية. يجعل Apidog هذه العملية سهلة بشكل لا يصدق.

باستخدام Apidog، يمكنك:

1. اختبار جميع الطرق بسهولة: خذ أي عنوان URL لنقطة نهاية وقم بالتبديل بسرعة بين طرق GET و POST و PUT و PATCH و DELETE بنقرة واحدة لمعرفة أي منها مدعوم.
2. التحقق من رأس Allow: عندما تحصل على استجابة 405، سيعرض لك Apidog بوضوح رأس Allow في تفاصيل الاستجابة. يمكنك التحقق من أنه يحتوي على القائمة الصحيحة للطرق.
3. أتمتة اختبار الطرق: إنشاء مجموعات اختبار تتحقق تلقائيًا من أن الطرق غير المدعومة تُرجع 405 مع رأس Allow المناسب، بينما تُرجع الطرق المدعومة حالة 2xx المتوقعة.
4. تصحيح أخطاء التعليمات البرمجية من جانب العميل: إذا كنت تقوم بإنشاء تطبيق عميل يتلقى 405، فيمكنك استخدام Apidog لتكرار الطلب والاستجابة بالضبط، مما يساعدك على فهم المشكلة وإصلاحها في التعليمات البرمجية للعميل.
5. توثيق سلوك API: استخدم Apidog لتوثيق الطرق المدعومة لكل نقطة نهاية، مما يجعل هذه المعلومات واضحة للمطورين الآخرين الذين يستهلكون واجهة برمجة التطبيقات الخاصة بك.

زر

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

أفضل الممارسات للتعامل مع 405s

لمطوري API (جانب الخادم):

• دائمًا قم بتضمين رأس Allow في استجابات 405. هذا ليس اختياريًا لخادم HTTP متوافق.
• كن متسقًا في استخدامك للطرق عبر واجهة برمجة التطبيقات الخاصة بك. إذا كانت معظم نقاط نهاية المجموعات تدعم GET و POST، فلا تجعل واحدة تدعم GET فقط بدون سبب وجيه.
• قدم رسالة خطأ مفيدة في نص الاستجابة، خاصة لواجهات برمجة التطبيقات التي يستهلكها مطورون آخرون.
• فكر في استخدام OPTIONS: قم بتطبيق طريقة OPTIONS لنقاط النهاية الخاصة بك، والتي يجب أن تُرجع نفس رأس Allow. يمنح هذا العملاء طريقة لاكتشاف الطرق المدعومة دون إثارة الأخطاء.

لمستهلكي API (جانب العميل):

• تحقق من رأس Allow عندما تتلقى 405. يخبرك بالضبط بما يمكنك فعله بدلاً من ذلك.
• استخدم طريقة OPTIONS لاكتشاف الطرق المدعومة قبل محاولة عمليات أخرى.
• تعامل مع أخطاء 405 بسلاسة في التعليمات البرمجية الخاصة بك - لا تعاملها كأخطاء قاتلة، ولكن كإرشاد حول كيفية تصحيح طلبك.

دور طريقة OPTIONS

طريقة OPTIONS هي الابن الاستباقي لاستجابة 405. بدلاً من محاولة عملية ورفضها، يمكن للعميل أولاً أن يسأل الخادم عن الطرق المدعومة:

الطلب:

OPTIONS /api/products/123 HTTP/1.1Host: api.example.com

الاستجابة:

HTTP/1.1 200 OKAllow: GET, HEAD, OPTIONS

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

استكشاف أخطاء 405 الشائعة وإصلاحها

• تحقق جيدًا من تعريفات المسارات ومعالجات أفعال HTTP.
• راجع تكوينات الوكيل أو جدار الحماية التي قد تحظر طرقًا معينة.
• ابحث عن الأخطاء الإملائية أو التناقضات في طلبات العميل.
• استخدم أدوات التصحيح مثل Apidog لالتقاط دورات الطلب/الاستجابة الكاملة.
• اختبر عبر البيئات لتحديد المشكلات الخاصة بالإنتاج.

الآثار الأمنية لـ 405

يمكن أن يكون لـ 405 أيضًا آثار أمنية:

• يساعد تعطيل الطرق غير الآمنة (مثل TRACE) في منع الهجمات.
• قد يكشف الكثير في رأس Allow عن تلميحات للمهاجمين.
• يمنع التعامل المتسق مع 405 تسريب تفاصيل الخادم.

الخلاصة: من الإحباط إلى الوضوح

رمز حالة 405 Method Not Allowed ليس مجرد عائق عشوائي. إنه إشارة قيمة إلى أن المورد موجود ولكنه لا يقبل الطريقة التي استخدمتها. رمز حالة HTTP 405 Method Not Allowed هو مثال مثالي على كيف يوفر تصميم API الجيد ملاحظات واضحة وقابلة للتنفيذ. إنه يحول ما يمكن أن يكون طريقًا مسدودًا مربكًا إلى لافتة إرشادية مفيدة تقول: "لا يمكنك الذهاب في هذا الاتجاه، ولكن إليك المسارات المفتوحة لك."

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

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

زر