बैकएंड इंटरव्यू: आप RFC 9457 के साथ HTTP API त्रुटियों का मानकीकरण कैसे करेंगे?

साक्षात्कारकर्ता क्या मूल्यांकन करता है

एक मल्टी-टेनेंट API गेटवे, एप्लिकेशन और एसिंक्रोनस जॉब्स से त्रुटियां उत्पन्न करता है, जिससे क्लाइंट विफलताओं को विश्वसनीय रूप से पार्स नहीं कर पाते हैं। RFC 9457 का उपयोग करके, एक साझा त्रुटि अनुबंध डिज़ाइन करें और स्टेटस कोड, मीडिया प्रकार, type URIs, बैच सत्यापन, पुनः प्रयास, रिडैक्शन और संस्करण संगतता की व्याख्या करें।

संदर्भ और सीमाएं

• एक अनुरोध CDN, API गेटवे, व्यावसायिक सेवा और कतार (queue) से होकर गुजर सकता है।
• क्लाइंट को ठीक करने योग्य इनपुट त्रुटियों, प्राधिकरण विफलताओं, थ्रॉटलिंग और क्षणिक (transient) दोषों के बीच अंतर करने में सक्षम होना चाहिए।
• विवरण में स्टैक, कुंजियाँ, टेनेंट-अलगाव डेटा या आंतरिक होस्टनाम उजागर नहीं होने चाहिए।
• मौजूदा क्लाइंट लीगेसी फ़ील्ड्स को पार्स करते हैं, इसलिए माइग्रेशन को बैकवर्ड कम्पैटिबल बनाए रखना होगा।

HTTP सिमेंटिक्स को व्यावसायिक विवरण से अलग करें

HTTP स्थिति प्रोटोकॉल-स्तरीय परिणाम व्यक्त करती है; Problem Details बॉडी कारण की व्याख्या करती है। प्रत्येक विफलता के लिए 200 वापस करने के बजाय उनके सिमेंटिक्स के अनुसार 400, 401, 403, 404, 409, 429 और 5xx चुनें। मशीन वर्गीकरण के लिए type में एक स्थिर URI, प्रस्तुतीकरण के लिए title, और अनुरोध-विशिष्ट detail का उपयोग करें।

एक न्यूनतम विस्तार योग्य अनुबंध परिभाषित करें

मुख्य सदस्य type, title, status, detail, और instance हैं। एक्सटेंशन को स्पष्ट रूप से नाम दें, जैसे फ़ील्ड समस्याओं के लिए errors और क्लाइंट प्रतीक्षा संकेत के लिए retryAfter। प्रत्येक प्रकार के दस्तावेज़ में इसका अर्थ, अनुमत स्थिति कोड और क्लाइंट की कार्रवाई का उल्लेख होना चाहिए; क्लाइंट को प्राकृतिक-भाषा शीर्षकों (titles) पर शाखाबद्ध (branch) नहीं होना चाहिए।

परतों के बीच एक त्रुटि सीमा साझा करें

गेटवे-जनरेटेड टाइमआउट, प्रमाणीकरण और थ्रॉटलिंग त्रुटियां समान मीडिया प्रकार का उपयोग करती हैं, लेकिन उन्हें एप्लिकेशन व्यावसायिक प्रकार का रूप नहीं लेना चाहिए। केवल स्वीकृत प्रकारों को उजागर करते हुए सेवाएँ टेलीमेट्री के लिए आंतरिक त्रुटि कोड रखती हैं। संवेदनशील विवरण टेक्स्ट को कॉपी किए बिना सेवाओं के बीच एक सहसंबंध आईडी (correlation ID) प्रसारित करें।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• क्या क्लाइंट स्थिति, type, या लीगेसी code पर शाखाबद्ध होते हैं? यह माइग्रेशन एडाप्टर को निर्धारित करता है।
• क्या एक प्रतिक्रिया में एकाधिक फ़ील्ड-सत्यापन विफलताएं हो सकती हैं? यह errors के आकार और ऑर्डरिंग गारंटी को निर्धारित करता है।
• क्या गेटवे व्यावसायिक त्रुटियों को समझ सकता है, या केवल बुनियादी ढांचे की त्रुटियों को ट्रांसपोर्ट और उत्पन्न कर सकता है? यह प्रकार के स्वामित्व को निर्धारित करता है।

30-सेकंड उत्तर रूपरेखा

"मैं सही HTTP स्थिति को सुरक्षित रखूंगा और स्थिर type, title, status, detail, और वैकल्पिक instance के साथ application/problem+json लौटाऊंगा। क्लाइंट स्थिति और type पर शाखाबद्ध होते हैं, कभी भी गद्य (prose) पर नहीं; गेटवे केवल अपने त्रुटि प्रकारों का स्वामी होता है। सत्यापन, पुनः प्रयास संकेत, सहसंबंध आईडी, और रिडैक्शन नियम संगतता मैट्रिक्स और वास्तविक अनुरोध पथ के माध्यम से सत्यापित एक संस्करणित अनुबंध बन जाते हैं।"

चरण-दर-चरण गहन विश्लेषण

त्रुटि-प्रकार रजिस्ट्री के साथ प्रारंभ करें। प्रत्येक प्रकार में एक URI, सार्वजनिक सदस्य, अनुमत स्थितियां, क्लाइंट कार्रवाई और सुरक्षा स्तर होता है। सत्यापन विफलताएं errors के तहत फ़ील्ड समस्याओं के साथ 400 का उपयोग करती हैं; गुम पहचान और अपर्याप्त अनुमति 401 और 403 बनी रहती हैं; ऑप्टिमिस्टिक-कॉनकरेंसी विरोध 409 का उपयोग करते हैं; थ्रॉटलिंग एक कार्रवाई योग्य प्रतीक्षा संकेत के साथ 429 का उपयोग करता है; अज्ञात दोष 500 या 503 और एक सामान्य सार्वजनिक प्रकार का उपयोग करते हैं।

Content-Type को निरूपण के साथ सुसंगत रखें। एक instance मान समर्थन के लिए एक अनुरोध की पहचान कर सकता है, लेकिन detail में पूर्ण URL, SQL, स्टैक ट्रेस या टेनेंट पहचानकर्ता शामिल नहीं होने चाहिए। लॉग आंतरिक कारण, सहसंबंध आईडी और सुरक्षा-ऑडिट फ़ील्ड रखते हैं; क्लाइंट को केवल नीति-फ़िल्टर की गई सामग्री प्राप्त होती है।

बैच सत्यापन के लिए, परिभाषित करें कि क्या कई समस्याओं की अनुमति है, फ़ील्ड पथ कैसे लिखे जाते हैं, और प्रविष्टियों की अधिकतम संख्या क्या है। क्लाइंट अज्ञात एक्सटेंशन सदस्यों को अनदेखा करते हैं। नए सदस्य योगात्मक (additive) हैं; मौजूदा type के अर्थ को बदलने के लिए एक नए URI की आवश्यकता होती है। एक एसिंक्रोनस कार्य समकालिक रूप से कतार के आंतरिक विवरण को लीक करने के बजाय कार्य संसाधन के माध्यम से अपनी विफलता को उजागर करता है।

मॉडल उच्च-गुणवत्ता उत्तर

"मैं एक प्रकार रजिस्ट्री बनाए रखूंगा और गेटवे, सिंक्रोनस सेवाओं और एसिंक्रोनस कार्यों को RFC 9457-संगत application/problem+json उत्सर्जित करने के लिए कहूंगा। स्थिति प्रोटोकॉल सिमेंटिक्स बताती है, type एक स्थिर श्रेणी बताता है, और detail केवल इस अनुरोध का वर्णन करता है। फ़ील्ड सत्यापन एक सीमित errors एक्सटेंशन का उपयोग करता है; 429 में एक पार्स करने योग्य प्रतीक्षा संकेत होता है; 500 और 503 सामान्य सार्वजनिक प्रकारों का उपयोग करते हैं जबकि स्टैक लॉग में रहते हैं। माइग्रेशन के दौरान मैं लीगेसी code रखता हूँ, फिर अनुबंध परीक्षणों, संगतता मैट्रिक्स और रिडैक्शन ऑडिट के माध्यम से क्लाइंट को स्विच करता हूँ।"

सामान्य गलतियाँ

• व्यावसायिक-विफलता फ़ील्ड के साथ 200 लौटाना, जिससे कैश, मॉनिटर और पुनः प्रयासकर्ता सफलता का अनुमान लगाते हैं।
• title या detail पर शाखाबद्ध होना, जिससे अनुवाद या शब्द-परिवर्तन क्लाइंट को तोड़ देते हैं।
• प्रत्येक सेवा को type URIs का आविष्कार करने की अनुमति देना, जो सुसंगत एकत्रीकरण को रोकता है।
• detail में स्टैक, SQL, आंतरिक डोमेन, या पूर्ण टेनेंट पहचानकर्ता लौटाना।
• गेटवे टाइमआउट को व्यावसायिक त्रुटि में बदलना, जिससे गलत पुनः प्रयास या उपयोगकर्ता मार्गदर्शन उत्पन्न होता है।

विफलता के लक्षण और समाधान

जब कोई क्लाइंट यह तय नहीं कर पाता कि पुनः प्रयास करना है या नहीं, तो स्थिति, प्रकार और पुनः प्रयास मार्गदर्शन आमतौर पर असहमत होते हैं। पहले रजिस्ट्री बनाएं, प्रत्येक परत को एक छोटे सार्वजनिक सेट पर मैप करें, अज्ञात प्रकारों के लिए एक सुरक्षित डिफ़ॉल्ट परिभाषित करें, और सहसंबंध आईडी के साथ आंतरिक कारण का पता लगाएं।

प्रोडक्शन कार्यान्वयन

सेवा सीमा पर स्थिति चयन को बनाए रखते हुए एक साझा लाइब्रेरी या एज एडाप्टर में सीरियलाइज़ेशन को केंद्रीकृत करें। स्कीमा सत्यापन एक्सटेंशन की लंबाई, सरणी गणना और URI प्रारूपों को सीमित करता है; केवल गेटवे पर भरोसा करने के बजाय सीरियलाइज़ेशन से पहले संवेदनशील डेटा को रिडैक्ट करें। पुनः प्रयास तूफानों (retry storms) से बचने के लिए 429, 503 और नेटवर्क टाइमआउट के लिए एक्सपोनेंशियल बैकऑफ़, जिटर और आइडम्पोटेंसी स्थितियों को अलग से परिभाषित करें।

सत्यापन चेकलिस्ट

अनुबंध परीक्षण प्रत्येक सार्वजनिक प्रकार की स्थिति, मीडिया प्रकार, आवश्यक सदस्यों और एक्सटेंशन को कवर करते हैं। एकीकरण परीक्षण गेटवे, सेवा और कतार को पार करते हैं और सहसंबंध आईडी और रिडैक्शन की पुष्टि करते हैं। संगतता परीक्षण अज्ञात-सदस्य सहनशीलता और संरक्षित code को सत्यापित करने के लिए एक लीगेसी क्लाइंट का उपयोग करते हैं। लोड परीक्षण सीरियलाइज़ेशन विलंबता, लॉग सैंपलिंग और थ्रॉटलिंग के तहत पुनः प्रयास प्रवर्धन को मापते हैं।

अनुवर्ती प्रश्न और उत्तर

एक ही व्यावसायिक त्रुटि कोड क्यों नहीं परिभाषित करते?

एक एकल कोड HTTP कैशिंग, प्रमाणीकरण, थ्रॉटलिंग और पुनः प्रयास सिमेंटिक्स को व्यक्त नहीं कर सकता है। स्थिति सामान्य बुनियादी ढांचे को सही ढंग से व्यवहार करने की अनुमति देती है; type स्थिर व्यावसायिक श्रेणी वहन करता है। उनकी अलग-अलग ज़िम्मेदारियाँ हैं।

क्या type URI का सुलभ (reachable) होना आवश्यक है?

विनिर्देश सापेक्ष या निरपेक्ष URIs की अनुमति देता है। एक स्थिर, दस्तावेजीकरण योग्य रूप चुनें, लेकिन दस्तावेज़ीकरण पृष्ठ की उपलब्धता को क्लाइंट प्रबंधन के लिए पूर्व शर्त न बनाएं।

आप त्रुटि बॉडी से डेटा लीक होने से कैसे रोकते हैं?

सार्वजनिक सदस्यों की अनुमति सूची, लंबाई सीमा और संवेदनशील-पैटर्न स्कैनिंग का उपयोग करें। आंतरिक अपवादों को सामान्य प्रकारों पर मैप करें और समर्थन के लिए केवल एक सहसंबंध आईडी बनाए रखें। सुरक्षा परीक्षण क्रॉस-टेनेंट क्वेरीज़, प्राधिकरण विफलताओं और अपवाद पथों को कवर करते हैं।

स्कोरिंग रूब्रिक

• सिमेंटिक सटीकता: HTTP स्थिति के अर्थ को Problem Details सदस्यों से अलग करता है।
• अनुबंध डिज़ाइन: स्थिर प्रकार, एक्सटेंशन और संस्करण का प्रस्ताव करता है।
• सीमा जागरूकता: गेटवे, कार्य, रिडैक्शन और पुनः प्रयास तूफानों को कवर करता है।
• कार्यान्वयन योग्यता: इसमें एक रजिस्ट्री, सीरियलाइज़ेशन सीमा, संगतता मैट्रिक्स और परीक्षण शामिल हैं।
• जोखिम नियंत्रण: लीक से बचाता है और अज्ञात प्रकारों को डिफ़ॉल्ट रूप से पुनः प्रयास योग्य नहीं मानता है।

अनुपालन जांच

पुष्टि करें कि स्थिति कोड, प्रकार फ़ील्ड, रिडैक्शन और पुनः प्रयास सीमाएं सुसंगत रहें।

साक्षात्कार उत्तर चेकलिस्ट

स्थिति सिमेंटिक्स के साथ प्रारंभ करें, फिर बताएं कि type मशीन-स्थिर पहचानकर्ता है और detail अनुबंध कुंजी नहीं है। गेटवे स्वामित्व, सत्यापन, पुनः प्रयास, रिडैक्शन और संगतता प्रमाण जोड़ें।

एक-वाक्य का निष्कर्ष

स्थिति द्वारा प्रोटोकॉल सिमेंटिक्स को व्यक्त करके, type द्वारा स्थिर वर्गीकरण को व्यक्त करके, और एक्सटेंशन द्वारा कार्रवाई योग्य विवरण व्यक्त करके त्रुटियों का मानकीकरण करें, जिसमें सुरक्षा और संगतता परीक्षण सीमा की रक्षा करते हैं।