परिदृश्य (Scenario)
एक बैच API किसी ऑर्डर को मान्य करती है, इन्वेंट्री आरक्षित करती है और ऑर्डर बनाती है। यदि इन्वेंट्री आरक्षण विफल हो जाता है, तो ऑर्डर निर्माण कभी नहीं चलता है। साक्षात्कारकर्ता आपसे त्रुटि प्रतिक्रिया (error response) डिज़ाइन करने और यह स्पष्ट करने के लिए कहता है कि क्या HTTP 424 उपयुक्त है।
यह क्या परीक्षण करता है
- मानकीकृत HTTP सिमेंटिक्स को टीम-विशिष्ट सम्मेलनों से अलग पहचानना।
- निर्भरता ग्राफ़ में आंशिक पूर्णता, छोड़े गए कार्य (skipped work) और अज्ञात परिणामों का निरूपण करना।
- इडेम्पोटेंसी (idempotency), पुनः प्रयास की शर्तों और त्रुटि विवरणों को एक अनुबंध के रूप में डिज़ाइन करना।
आदर्श उत्तर (Model answer)
424 की सीमा
424 (Failed Dependency) को WebDAV RFC 4918 द्वारा परिभाषित किया गया है: विधि पूरी नहीं की जा सकी क्योंकि कोई अन्य ऑपरेशन विफल हो गया था। यह प्रत्येक डाउनस्ट्रीम सेवा त्रुटि के लिए एक सामान्य उपनाम नहीं है। एक गैर-WebDAV API 424 को अपना सकती है, लेकिन इसके सार्वजनिक अनुबंध को अर्थ, क्लाइंट व्यवहार और संगतता अपेक्षाओं को परिभाषित करना होगा।
स्टेटस कोड चुनना
412 Precondition Failed: एक अनुरोध पूर्व-शर्त जैसे किIf-Matchसंतुष्ट नहीं हुई थी।409 Conflict: अनुरोध वर्तमान संसाधन स्थिति के साथ संघर्ष करता है, जैसे कि इन्वेंट्री संस्करण परिवर्तन।424 Failed Dependency: यह चरण उसी अनुरोध या वर्कफ़्लो में विफल हुए चरण पर स्पष्ट रूप से निर्भर करता है और इसलिए निष्पादित नहीं हुआ।5xx: सर्वर सेवा विफलता के कारण अनुरोध को पूरा नहीं कर सका, इसलिए नहीं कि अनुरोध संबंध अवरुद्ध चरण की व्याख्या करता है।
किसी निर्भरता के 500 को यंत्रवत 424 पर मैप न करें। पहले यह तय करें कि क्या इस वर्कफ़्लो में कोई चरण अवरुद्ध था और क्या क्लाइंट उस तथ्य के कारण कोई भिन्न कार्रवाई कर सकता है।
प्रतिक्रिया निकाय (Response body) और स्टेट मशीन
स्थिर type, title, status, और detail के साथ-साथ blockedBy, operationId, retryable, और completedSteps जैसे एक्सटेंशन के साथ RFC 9457 Problem Details का उपयोग करें। व्यावसायिक एक्सटेंशन अनुबंध का हिस्सा हैं और उन्हें संस्करण (versioning) की आवश्यकता होती है।
{
"type": "https://api.example.com/problems/failed-dependency",
"title": "Order creation was blocked",
"status": 424,
"detail": "Inventory reservation failed",
"blockedBy": "reserve-inventory",
"operationId": "op_123",
"retryable": true,
"completedSteps": ["validate-order"]
}पुनः प्रयास (Retries) और अज्ञात परिणाम
स्वचालित रूप से पुनः प्रयास केवल तभी करें जब retryable=true हो और समान इडेम्पोटेंसी कुंजी का उपयोग किया गया हो। यदि इन्वेंट्री आरक्षण कमिट होने के बाद कनेक्शन टूट जाता है, तो क्लाइंट टाइमआउट को 424 नहीं कह सकता क्योंकि सर्वर का परिणाम अज्ञात है; इसे operationId द्वारा क्वेरी करनी चाहिए। एक पूर्ण साइड इफ़ेक्ट को दूसरे अनुरोध को नया होने का नाटक करके वापस (roll back) नहीं किया जा सकता है; व्यवसाय की आवश्यकता होने पर मुआवज़ा (compensation) प्रदान करें।
सामान्य गलतियाँ
- 424 को सभी माइक्रोसर्विस त्रुटियों के लिए एक सार्वभौमिक स्थिति के रूप में मानना।
- बिना किसी स्थिर त्रुटि प्रकार या ऑपरेशन आईडी के केवल पाठ्य विवरण (prose) लौटाना।
- प्रत्येक 424 पर पुनः प्रयास करना और डुप्लिकेट आरक्षण या ऑर्डर बनाना।
- किसी आउटेज को 424 के पीछे छिपाना ताकि निगरानी (monitoring) वर्कफ़्लो ब्लॉकिंग को प्लेटफ़ॉर्म विफलता से अलग न कर सके।
अनुवर्ती प्रश्न (Follow-up questions)
क्या कोई बैच अनुरोध आंशिक रूप से सफल हो सकता है?
हाँ, लेकिन प्रति-आइटम स्थिति, इडेम्पोटेंसी जानकारी और निर्भरता विवरण लौटाएं। बैच HTTP स्थिति समग्र परिणाम का वर्णन करती है; यह अलग-अलग आइटम परिणामों को प्रतिस्थापित नहीं कर सकती। यदि व्यवसाय को परमाणुता (atomicity) की आवश्यकता है, तो बताएं कि क्या सभी परिवर्तन रोल बैक हो जाते हैं या कोई भी कमिट नहीं होता है।
409, 424 से बेहतर कब है?
संसाधन-संस्करण और इन्वेंट्री-स्थिति संघर्ष वर्तमान-संसाधन समस्याएं हैं और आमतौर पर 409 में उपयुक्त होती हैं। 424 का उपयोग तब करें जब वर्तमान चरण को छोड़ दिया गया हो क्योंकि उसी वर्कफ़्लो में कोई अन्य चरण विफल हो गया था।
क्या होगा यदि निर्भरता 503 लौटाती है?
यदि वर्तमान चरण अवरुद्ध है और अनुबंध इसे वर्कफ़्लो निर्भरता विफलता के रूप में मानता है, तो 424 इसके विवरण में मूल कारण को ले जा सकता है। यदि पूरी सेवा अनुपलब्ध है, तो 503 लौटाएं और Retry-After जैसे सेवा-स्तरीय सिग्नलों का उपयोग करें। निगरानी और क्लाइंट नीतियों को इन मामलों में अंतर करना चाहिए।
आप अनुबंध का परीक्षण कैसे करते हैं?
निर्भरता की सफलता, अस्वीकृति, टाइमआउट, कमिट के बाद कनेक्शन हानि, डुप्लिकेट इडेम्पोटेंसी कुंजी, आंशिक पूर्णता और पुनर्प्राप्ति प्रश्नों को कवर करें। केवल HTTP संख्या के बजाय स्थिति, Problem Details फ़ील्ड, अंतिम स्थिति और साइड-इफ़ेक्ट गणना की पुष्टि (assert) करें।
स्कोरिंग रूब्रिक
उत्तीर्ण (Passing)
424 की WebDAV उत्पत्ति की सटीक व्याख्या करता है, 409, 412 और 5xx के लिए सीमाएं तय करता है, और एक इडेम्पोटेंसी कुंजी के साथ अज्ञात-परिणाम क्वेरी का प्रस्ताव करता है।
मजबूत (Strong)
Problem Details एक्सटेंशन, आंशिक-पूर्णता अवस्थाओं, निगरानी श्रेणियों और सुरक्षित स्वचालित-पुनः प्रयास शर्तों को डिज़ाइन करता है।
उत्कृष्ट (Excellent)
व्यावसायिक परमाणुता, निर्भरता ग्राफ़, मुआवज़े और संस्करण अनुबंधों का उपयोग करके प्रत्येक विकल्प को सही ठहराता है, साथ ही WebDAV के बाहर 424 का उपयोग किए जाने पर संगतता जोखिम को इंगित करता है।
उत्तर रणनीति
पहले स्थिति कोड की मानक उत्पत्ति स्थापित करें, फिर चरण अवस्थाओं और साइड-इफ़ेक्ट सीमाओं को रेखांकित करें; अंत में एक क्वेरी-योग्य, पुनः प्रयास-सुरक्षित त्रुटि अनुबंध के साथ निर्णय को ठोस बनाएं।
स्रोत
स्थिति-कोड मानक
- RFC 4918: WebDAV (IETF)
HTTP सिमेंटिक्स
- RFC 9110: HTTP Semantics (IETF)
त्रुटि प्रारूप
- RFC 9457: Problem Details for HTTP APIs (IETF)