प्रश्न
आप एक फ़ाइल API का रखरखाव करते हैं: GET /v1/files/:id एक फ़ाइल पढ़ता है, लेकिन एक क्लाइंट उसी रिसोर्स पर POST या DELETE भेजता है। साक्षात्कारकर्ता आपसे रिस्पॉन्स डिज़ाइन करने और 405, 404, 403, OPTIONS और CORS प्रीफ़्लाइट के बीच अंतर समझाने के लिए कहता है। रूट मैचिंग, Allow हेडर, एरर बॉडी, टेस्ट और रोलआउट को कवर करें।
संदर्भ और बाधाएं
- रिसोर्स रूट एक ठोस फ़ाइल से मेल खाता है, लेकिन आज केवल
GETऔरHEADसक्षम हैं। - SDK संस्करण बेमेल होने के कारण एक अमान्य मेथड हो सकता है, और कोई प्रॉक्सी इसे रीराइट या इंटरसेप्ट कर सकती है।
- कॉल करने वालों को एक डायग्नोस करने योग्य रिस्पॉन्स की आवश्यकता होती है, जबकि अक्षम किए गए मेथड्स को उपलब्ध के रूप में विज्ञापित नहीं किया जाना चाहिए।
- यदि रिसोर्स का अस्तित्व संवेदनशील है, तो टीम API अनुबंध में प्रलेखित, एक सुसंगत 404 छिपाने की नीति का उपयोग कर सकती है।
साक्षात्कारकर्ता क्या जांच रहा है
रिसोर्स मैचिंग को मेथड डिस्पैच से अलग करें
पहले होस्ट, पाथ, वर्शन और रिसोर्स आइडेंटिफ़ायर का मिलान करें, फिर रिसोर्स के अनुमत मेथड सेट को देखें। जब पाथ अनुपस्थित हो तो 404 लौटाएं; जब पाथ मौजूद हो लेकिन मेथड उस सेट से बाहर हो तो 405 लौटाएं। प्राधिकरण अभी भी सुरक्षा नीति का पालन करता है: बिना अनुमति वाले प्रमाणित कॉलर को 403 प्राप्त हो सकता है। हर प्राधिकरण विफलता को 405 में न बदलें।
405 में Allow शामिल होना चाहिए
405 का अर्थ है कि सर्वर अनुरोध मेथड को पहचानता है लेकिन लक्षित रिसोर्स इसका समर्थन नहीं करता है। रिस्पॉन्स में Allow शामिल होना चाहिए, जिसमें उस रिसोर्स द्वारा वर्तमान में समर्थित मेथड्स को सूचीबद्ध किया गया हो, उदाहरण के लिए:
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS
Content-Type: application/problem+json
{"type":"about:blank","title":"Method Not Allowed","status":405,"detail":"Use one of the methods listed in Allow."}Allow रिसोर्स क्षमता का वर्णन करता है। यह CORS के Access-Control-Allow-Methods से अलग है, जो ब्राउज़र क्रॉस-ऑरिजिन नीति में भाग लेता है और 405 द्वारा व्यक्त HTTP मेथड अनुबंध को प्रतिस्थापित नहीं कर सकता है।
OPTIONS को अलग से मॉडल करें
OPTIONS संचार विकल्पों के बारे में पूछ सकता है। एक ब्राउज़र CORS प्रीफ़्लाइट Origin और Access-Control-Request-Method भी भेजता है। प्रीफ़्लाइट सफल होता है या नहीं यह CORS रिस्पॉन्स हेडर और प्रमाणीकरण नीति पर निर्भर करता है। प्रत्येक OPTIONS अनुरोध को 405 में न बदलें, और Allow को CORS प्राधिकरण सूची के रूप में न समझें।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या रिसोर्स वास्तव में मौजूद है? यदि नहीं, तो 404 का उपयोग करें; यदि कोई सुरक्षा नीति अस्तित्व को छिपाती है, तो पुष्टि करें कि क्या यह लगातार 404 लौटाती है।
- क्या अनुमत मेथड टेनेंट, रिसोर्स स्थिति या API वर्शन के अनुसार भिन्न हो सकते हैं? उत्तर
Allowऔर कैश कुंजी उत्पन्न करने के लिए उपयोग किए जाने वाले संदर्भ को बदलता है। - क्या गेटवे अज्ञात मेथड्स को फिर से लिखेगा (rewrite), और
Allowजनरेशन का स्वामी कौन है? उत्तर डिबगिंग सीमा और सत्य के एकल स्रोत (single source of truth) को परिभाषित करता है।
30-सेकंड उत्तर ढांचा
"पाथ मेल खाता है, लेकिन मेथड रिसोर्स के क्षमता सेट से बाहर है, इसलिए मैं 405 लौटाता हूँ और Allow में वास्तव में समर्थित मेथड्स को सूचीबद्ध करता हूँ। एक अनुपलब्ध पाथ 404 है, प्राधिकरण अस्वीकृति 403 नीति का पालन करती है, और OPTIONS तथा CORS प्रीफ़्लाइट अलग हेडर का उपयोग करते हैं। मैं एक मेथड मैट्रिक्स, एक वास्तविक गेटवे-पाथ टेस्ट और रोलआउट मेट्रिक्स के साथ समाप्त करूँगा।"
चरण-दर-चरण विस्तृत उत्तर
प्रत्येक रिसोर्स रूट के अनुमत मेथड्स को एक ऑडिट करने योग्य रजिस्ट्री में परिभाषित करें, फिर राउटर को डिस्पैच और Allow जनरेशन के लिए उसी रजिस्ट्री का उपयोग करने दें। POST /v1/files/123 के लिए, यदि रिसोर्स मौजूद है और POST पंजीकृत नहीं है, तो 405 लौटाएं; यदि 123 मौजूद नहीं है तो 404 लौटाएं; प्राधिकरण नीति द्वारा अस्वीकार किए गए मेल खाते अनुरोध के लिए 403 लौटाएं। HEAD अक्सर GET की पठनीय क्षमता का अनुसरण करता है, लेकिन फ्रेमवर्क का वास्तविक व्यवहार सत्य का स्रोत है।
एरर बॉडी को स्टैक ट्रेस या आंतरिक रूट विवरण उजागर किए बिना एक स्थिर स्थिति, शीर्षक और कार्रवाई योग्य स्पष्टीकरण प्रदान करना चाहिए। केवल उन मेथड्स को सूचीबद्ध करें जो वास्तव में Allow में सक्षम हैं; रोलआउट के दौरान, उन राइट (write) क्षमताओं का विज्ञापन न करें जो तैनात नहीं हैं। यदि सुरक्षा नीति रिसोर्स के अस्तित्व को छिपाती है, तो इसके 404-बनाम-405 विकल्प, लॉग फ़ील्ड और क्लाइंट पुनः प्रयास (retry) व्यवहार का दस्तावेजीकरण करें।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं पहले राउटर को यह स्थापित करने दूंगा कि फ़ाइल मौजूद है या नहीं, फिर एक मेथड रजिस्ट्री से डिस्पैच करूँगा। एक मौजूदा फ़ाइल के लिए जो एक अपंजीकृत POST प्राप्त करती है, 405 लौटाएं और GET, HEAD के साथ-साथ वास्तव में समर्थित OPTIONS को Allow में रखें; अनुपलब्ध फ़ाइल के लिए 404 लौटाएं और 403 के लिए प्राधिकरण नीति का पालन करें। CORS प्रीफ़्लाइट Access-Control-Allow-Methods का उपयोग करता है, Allow का नहीं। गेटवे और एप्लिकेशन को हेडर जनरेशन के लिए एक स्वामी मिलता है। अनुबंध परीक्षण (contract tests) प्रत्येक स्थिति और मेथड सेट की जांच करते हैं, जबकि रोलआउट मेथड द्वारा 405 की निगरानी करता है।"
सामान्य गलतियाँ
- किसी मौजूदा पाथ के लिए असमर्थित मेथड के साथ 404 लौटाना, जिससे कॉल करने वाले खराब URL और खराब मेथड के बीच अंतर करने में असमर्थ हो जाते हैं।
Allowके बिना 405 लौटाना, जिससे क्लाइंट समर्थित मेथड्स को खोजने में असमर्थ होते हैं और यह HTTP सेमेंटिक्स का उल्लंघन करता है।Allowके स्थान परAccess-Control-Allow-Methodsका उपयोग करना, जिससे HTTP क्षमता और ब्राउज़र क्रॉस-ऑरिजिन अनुमति के बीच भ्रम उत्पन्न होता है।- प्रत्येक प्राधिकरण विफलता को 405 के रूप में पुनर्गठित करना, जो सुरक्षा ऑडिट, निगरानी और क्लाइंट व्यवहार को दूषित करता है।
- गेटवे और एप्लिकेशन को अलग-अलग
Allowसेट उत्पन्न करने की अनुमति देना, जिससे प्रॉक्सी कैशिंग के बाद असंगत प्रतिक्रियाएँ उत्पन्न होती हैं।
त्रुटि, कारण, सुधार
405 को एक सामान्य विफलता मानना, Allow को छोड़ देना, या CORS हेडर को Allow के रूप में उपयोग करना कॉल करने वालों को बिना किसी अगली कार्रवाई के छोड़ देता है। पहले रिसोर्स का मिलान करके, एक ही मेथड रजिस्ट्री से स्टेटस और हेडर उत्पन्न करके, और 404, 403, 405 तथा प्रीफ़्लाइट का अलग से परीक्षण करके फ्लो को सही करें।
उत्पादन कार्यान्वयन
रूट्स और प्रॉक्सी का समन्वय करें
या तो एप्लिकेशन के 405 और Allow को गेटवे के माध्यम से पास करें या एक गेटवे स्वामी को परिभाषित करें और डुप्लिकेट अधिलेखन (duplicate overwrites) को रोकें। कैशिंग, इडेम्पोटेंसी, प्रमाणीकरण और पुनः प्रयास आवश्यकताओं सहित प्रति API वर्शन एक मेथड मैट्रिक्स बनाए रखें। यदि कोई प्रॉक्सी अज्ञात मेथड्स को GET में डाउनग्रेड करता है, तो पहले उस नीति को ठीक करें; अन्यथा एप्लिकेशन कभी वास्तविक मेथड को नहीं देखता है।
ऑब्जर्वेबिलिटी और अनुकूलता
फ़ाइल सामग्री को लॉग किए बिना अनुरोध मेथड, सामान्यीकृत पाथ, रूट वर्शन, रिस्पॉन्स स्थिति और अंतिम Allow सेट को लॉग करें। 405 प्राप्त करने के बाद, एक क्लाइंट को आँख बंद करके उसी मेथड को फिर से आज़माना बंद कर देना चाहिए और अनुबंध-समर्थित मेथड का उपयोग करना चाहिए या अपने SDK को अपग्रेड करना चाहिए। पुराने क्लाइंट्स के लिए, वर्शनयुक्त परिवर्तन के माध्यम से व्यवहार को कड़ा करने से पहले लॉग और दस्तावेज़ीकरण में दुरुपयोग का निरीक्षण करें।
सत्यापन चेकलिस्ट
अनुबंध परीक्षण (Contract tests)
प्रत्येक रिसोर्स के लिए एक मेथड मैट्रिक्स बनाएं जिसमें शामिल हो: पंजीकृत मेथड्स के लिए सफलता, अपंजीकृत मेथड के लिए 405, गायब पाथ के लिए 404, प्राधिकरण अस्वीकृति के लिए 403, और Allow तथा वास्तविक रूट के बीच समानता। स्टेटस, हेडर मेथड सेट, कंटेंट प्रकार और एरर-बॉडी फ़ील्ड का दावा करें।
एकीकरण और रिग्रेशन
गेटवे, लोड बैलेंसर और एप्लिकेशन व्यवहार को एक साथ सत्यापित करने के लिए एक वास्तविक HTTP क्लाइंट का उपयोग करें। OPTIONS और CORS प्रीफ़्लाइट का अलग से परीक्षण करें, यह पुष्टि करते हुए कि Access-Control-Allow-Methods, Allow को प्रतिस्थापित नहीं करता है। रोलआउट के दौरान, 405 दर, मेथड वितरण और एरर-बॉडी पार्स विफलताओं पर अलर्ट करें।
अनुवर्ती प्रश्न और उत्तर
405 के स्थान पर 404 कब लौटाया जा सकता है?
404 तब लौटाएं जब पाथ वास्तव में मौजूद न हो या जब कोई सुरक्षा नीति जानबूझकर रिसोर्स के अस्तित्व को छिपाती हो। उस विकल्प को रिसोर्स क्लास के लिए लगातार लागू करें और क्लाइंट्स, लॉग्स तथा मॉनिटरिंग के लिए इसे प्रलेखित करें; विभिन्न नोड्स को यादृच्छिक रूप से 404 या 405 नहीं लौटाना चाहिए।
क्या Allow में हमेशा OPTIONS शामिल होना चाहिए?
इसे केवल तभी शामिल करें जब रिसोर्स वास्तव में OPTIONS स्वीकार करता हो। यदि फ्रेमवर्क स्वचालित रूप से OPTIONS को संभालता है, तो सत्यापित करें कि इसका रिस्पॉन्स एप्लिकेशन रूट अनुबंध से मेल खाता है; केवल विज़ुअल पूर्णता के लिए किसी अनिर्धारित मेथड को न जोड़ें।
गतिशील क्षमताएं कैसे काम करनी चाहिए?
जब मेथड क्षमता टेनेंट, वर्शन या रिसोर्स स्थिति के अनुसार भिन्न होती है, तो वर्तमान अनुरोध संदर्भ से Allow उत्पन्न करें और कैश कुंजी में सभी क्षमता आयाम शामिल करें। एक सुरक्षित डिफ़ॉल्ट 405 की मध्यस्थ कैशिंग को सीमित करना या एक स्पष्ट कैश नीति सेट करना है।
स्कोरिंग रूब्रिक
- सेमेंटिक सटीकता: बताता है कि 405 कब लागू होता है और
Allowअनिवार्य क्यों है। - स्पष्ट सीमाएं: 404, 403,
OPTIONS, CORS और सुरक्षा छिपाव के बीच अंतर करता है। - व्यावहारिक कार्यान्वयन: ठोस रजिस्ट्री, प्रॉक्सी, एरर-बॉडी और ऑब्जर्वेबिलिटी विकल्प देता है।
- पूर्ण सत्यापन: मेथड मेट्रिसेस, वास्तविक HTTP पाथ, रोलआउट मेट्रिक्स और रिग्रेशन को कवर करता है।
- जोखिम जागरूकता: झूठे मेथड विज्ञापन, सूचना लीक और गेटवे/एप्लिकेशन ड्रिफ्ट से बचाता है।
संदर्भ
- MDN: 405 Method Not Allowed
- MDN: Allow header
- Postman: HTTP Error 405
- JustAcademy: REST API interview questions
उत्तर देने का सुझाव
"रिसोर्स मेल खा गया, मेथड असमर्थित है, 405 लौटाएं" से शुरू करें, फिर वास्तविक Allow सेट दें। 404, 403, OPTIONS और CORS में अंतर बताएं, और मेथड-मैट्रिक्स परीक्षणों और प्रॉक्सी निरंतरता के साथ समाप्त करें।
एक पंक्ति का निष्कर्ष
405 बताता है कि रिसोर्स-मेथड संयोजन अमान्य है, जबकि Allow क्लाइंट को बताता है कि कौन से मेथड वर्तमान में मान्य हैं; साथ में वे एक डायग्नोस करने योग्य HTTP अनुबंध बनाते हैं।