1. प्रॉम्ट और परिदृश्य
एक ऑर्डर API JSON रिक्वेस्ट्स स्वीकार करता है। एक क्लाइंट अमान्य फ़ील्ड संबंधों के साथ सिंटैक्टिकली मान्य डेटा भेज सकता है, पुराने वर्ज़न से ऑर्डर को अपडेट कर सकता है, या ऐसा यूज़रनेम बनाने का प्रयास कर सकता है जो पहले से मौजूद है। 409 और 422 की सीमा को इस तरह परिभाषित करें कि क्लाइंट्स को पता चले कि रिक्वेस्ट को एडिट करना है, रिसोर्स को दोबारा पढ़ना है, या पुनः प्रयास करना बंद करना है।
2. इंटरव्यूअर क्या टेस्ट कर रहा है
- क्या आप अनप्रोसेसेबल रिक्वेस्ट सिमेंटिक्स को वर्तमान रिसोर्स स्थिति (state) के साथ कन्फ्लिक्ट से अलग करते हैं।
- क्या आप जानते हैं कि अपरिवर्तित 422 रिक्वेस्ट को दोहराने से आम तौर पर वही परिणाम मिलता है।
- क्या आप कॉन्करेंसी कंट्रोल, आइडम्पोटेंट रिट्राय और एरर कॉन्ट्रैक्ट को आपस में जोड़ते हैं।
- क्या आप निकटवर्ती 400 और 412 रिस्पॉन्स को सही स्थान दे सकते हैं और पॉलिसी को सुसंगत रख सकते हैं।
3. पूछने के लिए स्पष्टीकरण प्रश्न
- क्या API ETags, वर्ज़न नंबर, या किसी अन्य ऑप्टिमिस्टिक कॉन्करेंसी मैकेनिज्म का उपयोग करता है?
- क्या "नाम पहले से मौजूद है" को फ़ील्ड नियम के रूप में मॉडल किया गया है या कलेक्शन की वर्तमान स्थिति के रूप में?
- क्या क्लाइंट रिसोर्स को दोबारा पढ़कर यूज़र को अंतर (diff) दिखा सकता है?
- क्या टीम पहले से ही एरर कोड, फ़ील्ड पाथ और रिट्राय व्यवहार को मानकीकृत करती है?
4. 30-सेकंड का उत्तर ढांचा
पहले कारण को वर्गीकृत करें। 422 तब लौटाएं जब सर्वर मीडिया प्रकार और सिंटैक्स को समझता है लेकिन रिक्वेस्ट के सिमेंटिक्स को प्रोसेस नहीं कर सकता है। 409 तब लौटाएं जब समझ में आने वाली रिक्वेस्ट टार्गेट रिसोर्स की वर्तमान स्थिति से टकराती है। अनपार्स करने योग्य रिक्वेस्ट के लिए 400 का उपयोग करें और असफल सशर्त-रिक्वेस्ट प्रीकंडीशन के लिए 412 का उपयोग करें जब यह सटीक कॉन्ट्रैक्ट हो। मशीन-पठनीय कोड, सुधार मार्गदर्शन और वर्ज़न जानकारी के साथ समाप्त करें।
5. चरण-दर-चरण समाधान
चरण एक: 422 की सीमा परिभाषित करें
422 का अर्थ है कि कंटेंट का प्रकार और सिंटैक्स समझ में आ गया है, लेकिन उसमें निहित निर्देशों को प्रोसेस नहीं किया जा सकता है। उदाहरणों में प्रारंभ तिथि से पहले की समाप्ति तिथि, अस्वीकृत enum मान, या एक अमान्य फ़ील्ड संयोजन शामिल हैं। यह विफलता आमतौर पर इस बात से स्वतंत्र होती है कि रिसोर्स को अंतिम बार किसने बदला था, इसलिए क्लाइंट को पेलोड को फिर से भेजने से पहले उसे संशोधित करना चाहिए।
चरण दो: 409 की सीमा परिभाषित करें
409 का अर्थ है कि रिक्वेस्ट टार्गेट रिसोर्स की वर्तमान स्थिति से टकराती है। विशिष्ट मामलों में पुराना वर्ज़न, शिप किए जा चुके ऑर्डर को रद्द करना, या किसी ऐसे रिसोर्स को बनाना शामिल है जो मौजूदा यूनिक रिसोर्स से टकराता है। जब सुरक्षित हो तो वर्तमान वर्ज़न, कन्फ्लिक्ट का प्रकार और एक व्यावहारिक अगला कदम शामिल करें।
चरण तीन: निकटवर्ती कोड्स को सही स्थिति दें
खराब JSON या रिक्वेस्ट को पार्स करने के लिए आवश्यक छूटे हुए सिंटैक्स के लिए 400 का उपयोग करें। If-Match वाली रिक्वेस्ट जो अपनी बताई गई शर्त में विफल रहती है, 412 का उपयोग कर सकती है; यह प्रत्येक सशर्त विफलता को 409 कहने से अधिक सटीक है। चुनी गई पॉलिसी को दस्तावेज़ीकृत करें ताकि एंडपॉइंट्स असंगत अर्थ न निकालें।
चरण चार: रिट्राय और एरर बॉडी डिज़ाइन करें
अपरिवर्तित 422 पेलोड को स्वचालित रूप से पुनः प्रयास न करें क्योंकि इसके फिर से विफल होने की उम्मीद है। 409 सुधार योग्य हो सकता है: कन्फ्लिक्ट का प्रकार अनुमति देने पर दोबारा पढ़ें, मर्ज करें और पुनः प्रयास करें, लेकिन कभी भी आंख मूंदकर लूप न करें। एक स्थिर code, फ़ील्ड पाथ या रिसोर्स पहचानकर्ता, वर्तमान वर्ज़न और सुधार मार्गदर्शन लौटाएं; क्रेडेंशियल्स और अन्य रहस्यों को रिस्पॉन्स और लॉग्स से बाहर रखें।
6. मॉडल उत्तर
मैं विफलता को पेलोड-सिमेंटिक समस्या या रिसोर्स-स्टेट रेस के रूप में वर्गीकृत करता हूं। उल्टी तिथि श्रेणियां, अमान्य enums और असंभव फ़ील्ड संयोजन 422 हैं। एक सर्वर जो रिक्वेस्ट को समझता है लेकिन एक शिप किया गया ऑर्डर, एक पुराना वर्ज़न, या एक मौजूदा यूनिक रिसोर्स देखता है, वह 409 लौटा सकता है। विकृत JSON 400 है, और पूरी न हुई If-Match शर्त 412 हो सकती है।
>
422 के लिए, मैं एक स्थिर बिज़नेस कोड और फ़ील्ड पाथ लौटाता हूं ताकि क्लाइंट डेटा को एडिट कर सके। 409 के लिए, मैं कन्फ्लिक्ट प्रकार और सर्वर वर्ज़न या स्थिति लौटाता हूं ताकि क्लाइंट दोबारा पढ़ सके और मर्ज करने, छोड़ने या पुनः प्रयास करने का विकल्प चुन सके। किसी भी स्टेटस से बिना शर्त रिट्राय ट्रिगर नहीं होना चाहिए; एक आइडम्पोटेन्सी की (idempotency key) डुप्लिकेट निष्पादन को रोकती है लेकिन कॉन्करेंसी कन्फ्लिक्ट को दूर नहीं करती है। मैं सभी एंडपॉइंट्स के लिए एक पॉलिसी दस्तावेज़ीकृत करता हूं और मॉनिटर करता हूं कि प्रत्येक एरर को कैसे सुधारा जाता है।
7. सामान्य गलतियाँ
- प्रत्येक बिज़नेस वैलिडेशन विफलता के लिए 409 लौटाना, यह संकेत देना कि रिसोर्स को दोबारा पढ़ने से यह ठीक हो जाएगा।
- वर्ज़न कन्फ्लिक्ट के लिए 422 लौटाना और स्थिति बदलने के संकेत को छिपाना।
- किसी भी स्टेटस के लिए असीमित स्वचालित रिट्राय जोड़ना और एक रिक्वेस्ट स्टॉर्म (request storm) उत्पन्न करना।
- बिना किसी स्थिर कोड, फ़ील्ड पाथ या सुधार निर्देश के केवल एक मानव-पठनीय संदेश लौटाना।
- यह परिभाषित किए बिना कि यह एक पेलोड नियम है या रिसोर्स-स्टेट कन्फ्लिक्ट, प्रत्येक "डुप्लिकेट" के लिए एक ही कोड चुनना।
8. फॉलो-अप प्रश्न और उत्तर
फॉलो-अप एक: क्या डुप्लिकेट यूज़रनेम 409 होना चाहिए या 422?
यदि विशिष्टता (uniqueness) को कलेक्शन की वर्तमान स्थिति के रूप में मॉडल किया गया है, तो 409 एक स्टेट कन्फ्लिक्ट की जानकारी देता है। यदि टीम इसे फ़ील्ड-सिमेंटिक वैलिडेशन के रूप में मॉडल करती है, तो 422 सुसंगत हो सकता है। एक सार्वभौमिक लेबल की तुलना में स्थिर कॉन्ट्रैक्ट और पूर्वानुमेय क्लाइंट व्यवहार अधिक महत्वपूर्ण हैं।
फॉलो-अप दो: क्या प्रत्येक 409 पुनः प्रयास योग्य (retryable) है?
नहीं। मर्ज करने के बाद वर्ज़न कन्फ्लिक्ट का पुनः प्रयास किया जा सकता है, जबकि शिप किए गए ऑर्डर को रद्द करने की प्रक्रिया बंद होनी चाहिए और वर्तमान स्थिति दिखानी चाहिए। रिस्पॉन्स को यह बताना चाहिए कि क्या कन्फ्लिक्ट सुधार योग्य है।
फॉलो-अप तीन: क्या 422 अनुमति विफलता (permission failure) का प्रतिनिधित्व कर सकता है?
इसे प्रमाणीकरण (authentication) और प्राधिकरण (authorization) सिमेंटिक्स को प्रतिस्थापित नहीं करना चाहिए। गुम प्रमाणीकरण आम तौर पर 401 होता है, और अनुमति के बिना एक प्रमाणित कॉलर आम तौर पर 403 होता है। 422 को उस कंटेंट के लिए आरक्षित रखें जिसके सिमेंटिक्स को प्रोसेस नहीं किया जा सकता है।