प्रॉम्ट और स्कोप
एक API एक बड़ा JSON डॉक्यूमेंट लौटाता है और क्लाइंट पिछला ETag स्टोर करके रखता है। बताएं कि HTTP 226 IM Used कब उपयुक्त होता है, क्लाइंट और सर्वर किन हेडर का आदान-प्रदान करते हैं, और डेल्टा लागू न होने पर शुद्धता (correctness) कैसे बनाए रखी जाती है। नेगोशिएशन, कैशिंग और फ़ॉलबैक को कवर करें; किसी विशिष्ट diff एल्गोरिदम की आवश्यकता नहीं है।
इंटरव्यूअर क्या जांच रहा है
- क्या आप जानते हैं कि 226, GET के लिए डेल्टा को दर्शाता है, न कि किसी मनमाने इनकम्प्लीट सक्सेस को।
- क्या आप
A-IM,IM,ETag, और वैकल्पिकDelta-Baseको एक एक्सचेंज में जोड़ सकते हैं। - क्या आप बेस-वर्जन, कैश-कॉनकरेंसी, एल्गोरिदम-कॉस्ट, और फुल-200 सीमाओं की पहचान करते हैं।
- क्या आप डिप्लॉयमेंट से पहले क्लाइंट्स, इंटरमीडियरीज़ और कैश में सपोर्ट को सत्यापित करेंगे।
स्पष्टीकरण वाले प्रश्न
- क्या क्लाइंट एक नेगोशिएटेड इंस्टेंस-मैनिपुलेशन एल्गोरिदम लागू कर सकता है?
- क्या डॉक्यूमेंट को एक स्थिर ETag द्वारा दृढ़ता से पहचाना जाता है, और क्या डेल्टा जनरेशन इसकी CPU लागत के लायक है?
- क्या कोई प्रॉक्सी रिस्पॉन्स को रीराइट या कैश करेगी, और क्या यह डेल्टा सिमेंटिक्स को बनाए रख सकती है?
- जब क्लाइंट का बेस पुराना या अमान्य हो, तो क्या वह पारदर्शी रूप से एक पूर्ण रिप्रेजेंटेशन प्राप्त कर सकता है?
30-सेकंड का उत्तर
मैं 226 को एक वैकल्पिक नेगोशिएटेड ऑप्टिमाइज़ेशन बनाऊंगा। क्लाइंट A-IM और बेस रिप्रेजेंटेशन का If-None-Match भेजता है। सर्वर 226 केवल तभी लौटाता है जब वह किसी एल्गोरिदम का समर्थन करता है और उसके पास वही सटीक बेस होता है, जो IM में एल्गोरिदम, एक नया ETag, और उपयोगी होने पर Delta-Base घोषित करता है। क्लाइंट बेस टैग को सत्यापित करता है, डेल्टा लागू करता है, और परिणामी एंटिटी टैग को मान्य करता है। मिसमैच, कम लागत-लाभ, असमर्थित क्लाइंट, या विफल मर्ज होने पर यह पूर्ण 200 पर वापस आ जाता है। कैश को केवल तभी डेल्टा का पुन: उपयोग करना चाहिए जब उसका बेस और रिस्पॉन्स मेटाडेटा मेल खाते हों।
चरण-दर-चरण डिज़ाइन
1. डेल्टा क्षमता को नेगोशिएट करें
A-IM क्लाइंट द्वारा स्वीकार किए गए इंस्टेंस-मैनिपुलेशन एल्गोरिदम को सूचीबद्ध करता है; सर्वर IM में अपनी पसंद का नाम देता है। यह कंटेंट-एन्कोडिंग कम्प्रेशन से अलग है: कम्प्रेशन ट्रांसफर कोडिंग को बदलता है, जबकि डेल्टा यह बदलता है कि रिप्रेजेंटेशन कैसे तैयार किया जाता है। पारस्परिक रूप से समर्थित एल्गोरिदम के बिना, 200 का उपयोग करें।
2. बेस को एक वर्जन से बाइंड करें
क्लाइंट अपने स्थानीय एंटिटी टैग की पहचान करने के लिए If-None-Match का उपयोग करता है। सर्वर को पुष्टि करनी चाहिए कि वह टैग बेस रिप्रेजेंटेशन से मैप होता है, न कि टाइमस्टैम्प या क्लाइंट द्वारा प्रदान किए गए वर्जन से अनुमान लगाना चाहिए। रिस्पॉन्स एक नया ETag ले जाता है; Delta-Base स्पष्ट रूप से बेस टैग की पहचान कर सकता है। क्लाइंट नए टैग के विरुद्ध मर्ज किए गए परिणाम को मान्य करता है।
3. फ़ॉलबैक को सुरक्षित बनाएं
यदि बेस गायब है, डेल्टा पूरे डॉक्यूमेंट से बड़ा है, एल्गोरिदम टाइम आउट हो जाता है, मर्ज सत्यापन विफल हो जाता है, या कोई इंटरमीडियरी असुरक्षित है, तो 200 लौटाएं। क्लाइंट को अनुपयोगी बेस को छोड़ देना चाहिए और पुनः सिंक्रनाइज़ करना चाहिए, ताकि एक खराब डेल्टा बाद के अपडेट को दूषित न कर सके। आकार, CPU और समय का बजट लागू करें।
4. कैश कीज़ और मेट्रिक्स को प्रोटोकॉल का हिस्सा मानें
कैश कीज़ में URL, नेगोशिएशन हेडर और बेस का चयन करने वाली शर्तें शामिल होनी चाहिए; एक ETag के लिए मान्य डेल्टा कोई जेनेरिक रिस्पॉन्स नहीं है। यह साबित करने के लिए कि ऑप्टिमाइज़ेशन अपनी जटिलता के लायक है, 226 हिट दर, डेल्टा बनाम पूर्ण बाइट्स, मर्ज विफलताएं, फ़ॉलबैक अनुपात और जनरेशन लेटेंसी को मापें।
मॉडल उच्च-गुणवत्ता उत्तर
मैं इसे एक स्पष्ट फ़ॉलबैक के साथ एक ऑप्टिमाइज़ेशन के रूप में शिप करूँगा। क्लाइंट समर्थित A-IM एल्गोरिदम का विज्ञापन करता है और अपने बेस के लिए If-None-Match भेजता है। सर्वर जाँचता है कि बेस मौजूद है और एल्गोरिदम अनुमत सूची में है, फिर डेल्टा आकार और जनरेशन लागत की तुलना करता है। केवल तभी यह 226 लौटाता है, IM के साथ एल्गोरिदम घोषित करता है, परिणाम का नया ETag जारी करता है, और वैकल्पिक रूप से Delta-Base के साथ बेस की पहचान करता है। क्लाइंट बेस टैग को सत्यापित करता है, डेल्टा लागू करता है, और अपने डॉक्यूमेंट को बदलने से पहले नए एंटिटी टैग को मान्य करता है। कोई भी वर्जन मिसमैच, अत्यधिक बड़ा डेल्टा, मर्ज विफलता, या असमर्थित पाथ 200 लौटाता है। कैश नेगोशिएशन और बेस स्थितियों के आधार पर भिन्न (vary) होते हैं, जबकि टेलीमेट्री सहेजे गए बाइट्स, CPU, विफलताओं और फ़ॉलबैक को रिकॉर्ड करती है। डेल्टा सपोर्ट शुद्धता की पूर्व शर्त बने बिना ट्रांसफर दक्षता में सुधार करता है।
सामान्य गलतियाँ
- 226 को 206 के रूप में मानना, भले ही 206 एक Range अनुरोध का उत्तर देता हो।
- सटीक बेस को ETag के साथ बाइंड करने के बजाय केवल एक अनौपचारिक वर्जन संख्या भेजना।
- यह मान लेना कि प्रत्येक ब्राउज़र, प्रॉक्सी और कैश डेल्टा सिमेंटिक्स को समझता है।
- डेल्टा आकार और पूर्ण-डॉक्यूमेंट आकार के बीच तुलना को छोड़ देना।
- मर्ज विफलता के बाद पुनः सिंक्रनाइज़ करने के बजाय अमान्य बेस से जारी रखना।
- कम्प्रेशन, JSON Patch और RFC 3229 इंस्टेंस मैनिपुलेशन को एक ही प्रोटोकॉल लेयर मानना।
फ़ॉलो-अप प्रश्न और उत्तर
226, 206 और 304 से किस प्रकार भिन्न है?
206, Range के साथ अनुरोधित बाइट रेंज लौटाता है; 304 कहता है कि कंडीशनल अनुरोध को किसी नए रिप्रेजेंटेशन की आवश्यकता नहीं है; 226 किसी मौजूदा रिप्रेजेंटेशन पर आधारित डेल्टा लौटाता है। उनकी अनुरोध शर्तें, क्लाइंट प्रोसेसिंग और कैश सिमेंटिक्स भिन्न हैं।
क्या होगा यदि बेस ETag पुराना हो?
डेल्टा को आँख मूंदकर लागू न करें। एक पूर्ण 200 लौटाएं या क्लाइंट से वर्तमान बेस प्राप्त करवाएं, अनुपयोगी स्थानीय बेस को त्यागें, और एक पूर्ण रिप्रेजेंटेशन से अपने कैश को फिर से बनाएं।
आप डेल्टा-कैश पॉइज़निंग को कैसे रोकते हैं?
URL, नेगोशिएटेड एल्गोरिदम, बेस ETag, और रिस्पॉन्स ETag को बाइंड करें; IM और Delta-Base को मान्य करें; इंटरमीडियरीज़ को किसी अन्य बेस के लिए डेल्टा का पुन: उपयोग करने से रोकें; और मर्ज की गई एंटिटी की अखंडता (integrity) को सत्यापित करें।