प्रॉम्ट और दायरा
यह बैकएंड प्रश्न API अनुबंधों और विफलता सीमाओं का परीक्षण करता है। इसका लक्ष्य प्रत्येक एक्सेप्शन को एक JSON ऑब्जेक्ट में लपेटना नहीं है, बल्कि क्लाइंट्स को एक स्थिर कार्रवाई करने देना है, जबकि लॉग, ट्रेसिंग, अनुमतियां और उपयोगकर्ता-उन्मुख भाषा अलग-अलग लेयर्स के रूप में बने रहें।
साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है
- क्या आप
application/problem+jsonऔर HTTP स्टेटस कोड के बीच के संबंध को समझते हैं। - क्या वैलिडेशन, प्रमाणीकरण (authentication), प्राधिकरण (authorization), टकराव (conflicts), दर सीमाएं (rate limits), अस्थायी विफलताएं और अज्ञात एरर अलग-अलग हैं।
- क्या आप फ़ील्ड-स्तरीय एरर, ट्रेस करने योग्य इंस्टेंस और नियंत्रित एक्सटेंशन मेंबर्स डिज़ाइन करते हैं।
- क्या आप स्टैक, आंतरिक ID, व्यक्तिगत डेटा और अविश्वसनीय रॉ एक्सेप्शन को उजागर करने से बचते हैं।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
पुष्टि करें कि क्या क्लाइंट्स को मशीन स्तर के निर्णयों की आवश्यकता है या केवल प्रदर्शित करने वाले टेक्स्ट की, क्या स्थानीयकरण, बैच वैलिडेशन और एसिंक्रोनस कार्य मौजूद हैं, क्या प्रकार सेवाओं के बीच साझा किए जाते हैं, कौन सी स्थितियां पुनः प्रयास योग्य (retryable) हैं, और गेटवे, सेवा व क्लाइंट प्रत्येक क्या लॉग करते हैं, प्रदर्शित करते हैं और अनुरोध सहसंबंध (request correlation) के लिए उपयोग करते हैं।
30-सेकंड की उत्तर संरचना
एक स्थिर आधार के रूप में application/problem+json के साथ type, title, status, detail और instance का उपयोग करें। कोड, फ़ील्ड पाथ, पुनः प्रयास समय और दस्तावेज़ीकरण संस्करण के लिए नियंत्रित एक्सटेंशन जोड़ें। HTTP स्टेटस सामान्य सिमेंटिक्स को वहन करता है और type एक प्रोग्राम करने योग्य श्रेणी को वहन करता है; आंतरिक कारण लॉग में रहते हैं जबकि रिस्पॉन्स में सुरक्षित, कार्रवाई योग्य जानकारी होती है।
गहन उत्तर
1. स्टेटस और प्रकार की सीमाएं स्थापित करें
सिंटैक्स या सामान्य अनुरोध विफलताओं के लिए 400, अनुपलब्ध प्रमाणीकरण के लिए 401, एक पहचानी गई लेकिन अस्वीकृत अनुरोध के लिए 403, अनुपलब्ध संसाधन के लिए 404, वर्तमान-स्थिति के टकराव के लिए 409, दर सीमित करने (rate limiting) के लिए 429 और सर्वर या निर्भरता विफलताओं के लिए 5xx का उपयोग करें। type को एक स्थिर, प्रलेखित URI बनाएं; क्लाइंट्स को अस्थिर title या detail टेक्स्ट को पार्स नहीं करना चाहिए।
2. Problem Details फ़ील्ड्स डिज़ाइन करें
type समस्या को वर्गीकृत करता है, title एक स्थिर मानव सारांश है, status रिस्पॉन्स को दर्शाता है, detail इस अनुरोध की व्याख्या करता है, और instance इस घटना की पहचान करता है। एक्सटेंशन में सीमित शब्दावली और लंबाई के साथ कोड, फ़ील्ड पाथ, पैरामीटर नाम, पुनः प्रयास समय या दस्तावेज़ीकरण संस्करण शामिल हो सकते हैं। बैच वैलिडेशन एक ऐरे लौटा सकता है जहाँ प्रत्येक आइटम एक इनपुट स्थान की ओर संकेत करता है।
3. वैलिडेशन, टकराव और पुनः प्रयासों को संभालें
वैलिडेशन विफलताओं को क्लाइंट्स को यह बताना चाहिए कि फ़ील्ड को कैसे ठीक किया जाए और उन्हें पुनः प्रयास का अनुरोध नहीं करना चाहिए। किसी टकराव के लिए फिर से पढ़ने या एक अलग व्यावसायिक कार्रवाई की आवश्यकता होती है। 429 या अस्थायी निर्भरता विफलता में Retry-After शामिल हो सकता है, लेकिन क्लाइंट्स को अभी भी बैकऑफ़ और प्रयास सीमा की आवश्यकता होती है। क्लाइंट्स से 200 रिस्पॉन्स के समुद्र से इसका अनुमान लगाने के लिए कहने के बजाय पुनः प्रयास की योग्यता (retryability) को स्पष्ट करें।
4. सुरक्षा और गोपनीयता सीमाओं की रक्षा करें
कभी भी स्टैक, SQL, कुंजियाँ (keys), आंतरिक होस्टनाम, क्रॉस-टेनेंट विवरण या पूर्ण व्यक्तिगत रिकॉर्ड शामिल न करें। Detail में केवल एक कार्रवाई योग्य तथ्य होना चाहिए; instance एक अप्रत्याशित या नियंत्रित संदर्भ होना चाहिए। आंतरिक लॉग में रॉ एक्सेप्शन को एक अनुरोध ID के साथ सहसंबद्ध करें। प्रमाणीकरण एरर में खाता-गणना (account-enumeration) लीक से बचें और अनुमति के आधार पर फ़ील्ड एरर को फ़िल्टर करें।
5. सेवाओं और संस्करणों के बीच विकास
साझा प्रकारों, स्टेटस और एक्सटेंशन को संस्करणयुक्त दस्तावेज़ीकरण और अनुबंध परीक्षणों में रखें; एक गेटवे को सेवा सिमेंटिक्स को दोबारा नहीं लिखना चाहिए। फ़ील्ड्स को सुसंगत रूप से जोड़ें और सेवानिवृत्त प्रकारों के लिए एक माइग्रेशन अवधि प्रदान करें। क्लाइंट्स को किसी अज्ञात प्रकार के लिए स्टेटस और सुरक्षित विवरण पर फ़ालबैक करना चाहिए। प्रकार वितरण, पुनः प्रयास सफलता, फ़ील्ड-एरर हॉटस्पॉट और अनुरोध-ID ट्रेसिबिलिटी की निगरानी करें।
एक मजबूत उत्तर का उदाहरण
मैं प्रत्येक एरर को एक स्थिर type URI, title, status, detail और instance के साथ application/problem+json के रूप में घोषित करूँगा। HTTP सिमेंटिक्स द्वारा 400/401/403/404/409/429 और 5xx में अंतर करें; वैलिडेशन के लिए फ़ील्ड पाथ और एक सुरक्षित कोड जोड़ें, और दर सीमित करने या अस्थायी निर्भरता विफलता के लिए Retry-After जोड़ें। अस्थिर विवरण को पार्स करने के बजाय क्लाइंट्स यह तय करने के लिए type का उपयोग करते हैं कि क्या सही करना है, फिर से प्राप्त करना है, बैकऑफ़ करना है, या समर्थन से संपर्क करना है। आंतरिक लॉग स्टैक, निर्भरता स्थिति और अनुरोध ID को बनाए रखते हैं, जबकि रिस्पॉन्स SQL, कुंजियों, टेनेंट डेटा और व्यक्तिगत रिकॉर्ड को बाहर रखते हैं। संस्करणयुक्त प्रकार और अनुबंध परीक्षण क्रॉस-सर्विस विकास की रक्षा करते हैं; अज्ञात प्रकार स्टेटस पर फ़ालबैक करते हैं। लॉन्च के बाद एरर प्रकारों, पुनः प्रयास परिणामों और फ़ील्ड हॉटस्पॉट की निगरानी करें।
सामान्य गलतियाँ
- प्रत्येक एरर के लिए 200 और एक वाक्य लौटाना, जिससे क्लाइंट प्रोग्रामेटिक रूप से निर्णय लेने में असमर्थ हो जाएं।
- क्लाइंट्स को शाब्दिक title या detail के शब्दों पर निर्भर बनाना, जिससे अनुवाद व्यवहार को तोड़ देता है।
- वैलिडेशन, टकराव, दर सीमाओं और अस्थायी विफलताओं को 500 के रूप में लेबल करना।
- detail में स्टैक, SQL, आंतरिक होस्टनाम या पूर्ण उपयोगकर्ता डेटा लौटाना।
- आंतरिक एक्सेप्शन क्लास नामों को सार्वजनिक प्रकारों के रूप में उजागर करना और अनुबंध में कार्यान्वयन विवरणों को फ्रीज करना।
- कोई अज्ञात-प्रकार फ़ालबैक या क्रॉस-सर्विस अनुबंध परीक्षण न होना।
अनुवर्ती प्रश्न
क्या type एक पहुँच योग्य URL होना चाहिए?
यह एक स्थिर URI होना चाहिए और व्याख्यात्मक दस्तावेज़ीकरण की ओर संकेत कर सकता है, लेकिन क्लाइंट्स को हैंडलिंग के लिए नेटवर्क अनुरोध की आवश्यकता नहीं होनी चाहिए। महत्वपूर्ण गुण सिमेंटिक पहचान, संस्करण और माइग्रेशन मार्गदर्शन हैं।
क्या detail को स्थानीयकृत किया जाना चाहिए?
मशीन फ़ील्ड और type को स्थिर रखें और क्लाइंट पर उसकी भाषा और संदर्भ के लिए उपयोगकर्ता पाठ प्रस्तुत करें। यदि सर्वर को detail लौटाना ही है, तो सुरक्षित टेम्पलेट्स और भाषा वार्ता का उपयोग करें; कभी भी किसी अनूदित आंतरिक एक्सेप्शन को उजागर न करें।
क्या गेटवे को प्रत्येक एरर को दोबारा लिखना चाहिए?
यह अनुरोध ID, टाइमआउट एरर और प्रोटोकॉल-स्तरीय विफलताओं को जोड़ सकता है, लेकिन इसे व्यावसायिक प्रकारों को संरक्षित रखना चाहिए। दोबारा लिखने के लिए संस्करणयुक्त नियमों और अवलोकन क्षमता की आवश्यकता होती है अन्यथा क्लाइंट्स को ऐसे सिमेंटिक्स दिखाई देंगे जो अब वास्तविक कारण से मेल नहीं खाते हैं।
आप एक बैच अनुरोध में आंशिक सफलता को कैसे संभालते हैं?
प्रति-आइटम स्थिति, इनपुट स्थान और पुनः प्रयास योग्यता के साथ एक बैच परिणाम को परिभाषित करें, और बताएं कि समग्र HTTP स्थिति का क्या अर्थ है। एक अस्पष्ट विवरण आंशिक सफलता व्यक्त नहीं कर सकता है, और क्लाइंट्स को उन मदों को दोबारा सबमिट नहीं करना चाहिए जो पहले ही सफल हो चुके हैं।