सामान्य साक्षात्कार: HTTP 428 Precondition Required खोए हुए अपडेट (lost updates) को कैसे रोकता है?

प्रॉम्प्ट और संदर्भ

दो क्लाइंट एक ही दस्तावेज़ को संपादित करते हैं। सर्वर को सशर्त अपडेट की आवश्यकता होती है: शर्त गायब होने पर यह 428 लौटाता है और दी गई शर्त का मिलान न होने पर 412 लौटाता है। बताएं कि ETag, If-Match, कैशिंग और पुनः प्रयास (retries) एक साथ कैसे काम करते हैं ताकि बाद का लेखन पहले के लेखन को चुपचाप अधिलेखित (overwrite) न कर सके।

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

• नीति आवश्यकता के रूप में 428 और मूल्यांकन की गई शर्त की विफलता के रूप में 412 में अंतर करना।
• आशावादी समवर्ती नियंत्रण (optimistic concurrency control) के लिए एक मजबूत ETag और If-Match का उपयोग करना।
• पढ़ने (read), संपादित करने (edit), सबमिट करने (submit), टकराव-प्रदर्शन (conflict-display), और मर्ज (merge) चरणों को डिज़ाइन करना।
• कैशिंग, इडेम्पोटेंसी (idempotency), ऑडिटेबिलिटी (auditability), और पुनः प्रयास सीमाओं को संभालना।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

1. किन संसाधनों और लेखन विधियों के लिए शर्तों की आवश्यकता है, और क्या If-Match: * की अनुमति है?
2. क्या ETag मजबूत (strong) है या कमजोर (weak), और क्या यह प्रत्येक संरक्षित प्रतिनिधित्व अपडेट के साथ बदलता है?
3. क्लाइंट को क्रमशः 428, 412, 404 और 409 को कैसे संभालना चाहिए?
4. क्या टकरावों को फ़ील्ड द्वारा मर्ज किया जाता है, उपयोगकर्ता द्वारा चुना जाता है, या छोड़ दिया जाता है?
5. कैश, संस्करण, इडेम्पोटेंसी-कुंजी (idempotency-key), और ऑडिट आवश्यकताएं क्या हैं?

30-सेकंड उत्तर ढांचा

क्लाइंट संसाधन पर GET करता है और उसके ETag को सहेजता है, फिर If-Match के साथ संपादन सबमिट करता है। एक गायब शर्त 428 प्राप्त करती है, जो क्लाइंट को एक शर्त जोड़ने के लिए कहती है; एक बेमेल 412 प्राप्त करता है, जो इसे बताता है कि संसाधन बदल गया है। क्लाइंट अंधाधुंध अधिलेखित करने के बजाय फिर से पढ़ता है, अंतर दिखाता है, मर्ज करता है, और नए ETag के साथ सबमिट करता है। सर्वर एक मजबूत ETag की परमाणु रूप से (atomically) तुलना करता है, संस्करणों और ऑडिट डेटा को रिकॉर्ड करता है, और सशर्त कैशिंग को लेखन सुरक्षा से अलग रखता है।

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

चरण 1: 428 और 412 को अलग करें

428 एक सर्वर नीति प्रतिक्रिया है: अनुरोध में एक आवश्यक पूर्व शर्त छोड़ दी गई थी। 412 का अर्थ है कि आपूर्ति की गई शर्त का मूल्यांकन किया गया था और वर्तमान संसाधन स्थिति ने इसे संतुष्ट नहीं किया। दोनों में से किसी का भी मतलब मूल अनुरोध को बिना बदलाव के पुनः प्रयास करना नहीं है।

चरण 2: एक संसाधन संस्करण उत्पन्न करें

सर्वर एक मजबूत ETag जारी करता है और जब भी संरक्षित प्रतिनिधित्व बदलता है तो इसे बदल देता है। क्लाइंट केवल स्थानीय टाइमस्टैम्प पर भरोसा करने के बजाय अपने संपादन बेसलाइन के रूप में GET से उस ETag को संग्रहीत करता है।

चरण 3: If-Match सबमिट करें

क्लाइंट PUT, PATCH, या किसी अन्य साइड-इफ़ेक्ट वाले अपडेट के साथ If-Match भेजता है। लिखने से पहले, सर्वर परमाणु रूप से वर्तमान ETag की तुलना करता है; केवल मिलान होने पर ही आगे बढ़ता है, जबकि बेमेल होने पर 412 लौटाता है और संसाधन को अपरिवर्तित छोड़ देता है।

GET /documents/42
ETag: "v17"

PUT /documents/42
If-Match: "v17"

चरण 4: टकराव को हल करें

412 के बाद, फिर से GET करें और स्थानीय परिवर्तनों के साथ सर्वर संस्करण दिखाएं। जब नीति अनुमति दे तो फ़ील्ड मर्ज करें; अन्यथा उपयोगकर्ता को चुनने के लिए कहें। कभी भी पुराना If-Match मान दोबारा न भेजें।

चरण 5: कैश व्यवहार डिज़ाइन करें

सशर्त GET If-None-Match का उपयोग कर सकता है और 304 प्राप्त कर सकता है, जबकि लेखन सुरक्षा If-Match का उपयोग करती है। कैश को पुराने ETag को वर्तमान नहीं मानना चाहिए या संसाधन की स्थिति को प्रकट करने वाले तरीके से त्रुटि को कैश नहीं करना चाहिए।

चरण 6: विफलताओं और पुनः प्रयासों को संभालें

नेटवर्क टाइमआउट के बाद, गैर-इडेम्पोटेंट (non-idempotent) लेखन को आँख बंद करके दोबारा न चलाएं। परिणाम स्थापित करने के लिए संसाधन संस्करण से पूछताछ करें या इडेम्पोटेंसी कुंजी का उपयोग करें। 428 को एक पूर्व शर्त की आवश्यकता होती है; 412 को फिर से पढ़ने और मर्ज करने की आवश्यकता होती है।

चरण 7: रिकॉर्ड और सत्यापित करें

संस्करणों, ETags, टकरावों की संख्या, स्वचालित-मर्ज दर, और उपयोगकर्ता परित्याग को ट्रैक करें। एक समवर्ती-अपडेट परीक्षण को एक लेखक के सफल होने और दूसरे को 412 प्राप्त करने के साथ-साथ प्रत्येक संस्करण परिवर्तन के लिए एक ऑडिट ट्रेल दिखाना चाहिए।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं GET से "v17" जैसा एक मजबूत ETag लौटाऊंगा और संपादन के दौरान क्लाइंट से इसे बनाए रखने को कहूंगा। If-Match के बिना PUT एक सशर्त अपडेट का उपयोग करने के निर्देश के साथ 428 लौटाता है; एक पुराना ETag परमाणु तुलना में विफल हो जाता है और 412 लौटाता है। क्लाइंट तब नवीनतम संस्करण को GET करता है, अंतर प्रदर्शित करता है, मर्ज करता है, और पुरानी स्थिति को दोबारा चलाने के बजाय नए ETag के साथ पुनः प्रयास करता है। If-None-Match और 304 पढ़ने को अनुकूलित करते हैं लेकिन लेखन की रक्षा नहीं करते हैं। टाइम-आउट लेखन को किसी भी पुनरावृत्ति से पहले संस्करण या इडेम्पोटेंसी कुंजी द्वारा जांचा जाता है, और हम टकराव और मर्ज दरों की निगरानी करते हैं।

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

• 428 और 412 दोनों को क्षणिक त्रुटियां मानना और हमेशा के लिए पुनः प्रयास करते रहना।
• मजबूत ETag तुलना को क्लाइंट टाइमस्टैम्प से बदलना।
• 412 प्राप्त करने के बाद सर्वर संस्करण को अधिलेखित करना।
• If-None-Match कैश सत्यापन को If-Match लेखन सुरक्षा के साथ भ्रमित करना।
• टाइमआउट के बाद बिना शर्त साइड-इफ़ेक्ट वाले लेखन को दोबारा चलाना।

फॉलो-अप और उत्तर

फॉलो-अप 1: Last-Modified का उपयोग क्यों न करें?

टाइमस्टैम्प सटीकता और घड़ी की समस्याएं दो संस्करणों को समान बना सकती हैं। एक मजबूत ETag सीधे प्रतिनिधित्व संस्करण से बंधता है और खोए हुए अपडेट को रोकने के लिए बेहतर है।

फॉलो-अप 2: If-Match: * कब उपयोगी है?

यह व्यक्त करता है कि संसाधन मौजूद होना चाहिए या API अनुबंध के आधार पर अज्ञात संस्करण के विरुद्ध निर्माण या प्रतिस्थापन को रोकता है। यह एक बिना शर्त लेखन नहीं है।

फॉलो-अप 3: 412, 409 से कैसे भिन्न है?

412 का अर्थ है कि एक HTTP पूर्व शर्त संतुष्ट नहीं थी। 409 का अर्थ है कि अनुरोध व्यावसायिक स्तर पर वर्तमान संसाधन स्थिति के साथ टकराता है। एक API दोनों का उपयोग कर सकता है लेकिन उसे पुनर्प्राप्ति कार्रवाई का उल्लेख करना चाहिए।

फॉलो-अप 4: आप फ़ील्ड स्तर पर कैसे मर्ज करेंगे?

सामान्य बेसलाइन, सर्वर संस्करण और स्थानीय संस्करण लोड करें, फिर फ़ील्ड नीति के अनुसार मर्ज करें। उपयोगकर्ता को समान-फ़ील्ड टकराव भेजें और नए ETag के साथ परिणाम सबमिट करें।

फॉलो-अप 5: क्या होगा यदि कोई कैश पुराना ETag लौटाता है?

संपादन से पहले उपयुक्त कैश नियंत्रण या पुनर्सत्यापन (revalidation) का उपयोग करें और विफल अपडेट के बाद ओरिजिन से पढ़ने के लिए बाध्य करें। वर्तमान संस्करण के साथ सर्वर की परमाणु तुलना आधिकारिक बनी रहती है।

फॉलो-अप 6: आप समवर्ती सुरक्षा का परीक्षण कैसे करते हैं?

दो क्लाइंट्स से एक ETag को पढ़वाएं और समवर्ती रूप से लिखवाएं। सत्यापित करें कि ठीक एक सफल होता है और दूसरा 412 प्राप्त करता है, फिर पुनः प्रयास, टाइमआउट, कैश और ऑडिट पथ को कवर करें।