प्रॉम्प्ट और संदर्भ
एक ऑनलाइन API को अपने रिसोर्स पाथ को /v1/orders से /v2/orders पर स्थायी रूप से स्थानांतरित करना है। कॉल करने वालों में ब्राउज़र फॉर्म, मोबाइल क्लाइंट, थर्ड-पार्टी SDK और एसिंक्रोनस वर्कर्स शामिल हैं; अनुरोध बड़ी JSON बॉडी और एक idempotency key के साथ POST हो सकते हैं। माइग्रेशन के लिए स्टेटस कोड, क्लाइंट व्यवहार, ऑब्जर्वेबिलिटी और रोलबैक पाथ डिज़ाइन करें।
यह प्रश्न यह जांचता है कि क्या आप रीडायरेक्ट सेमेंटिक्स को सटीक रूप से लागू कर सकते हैं और API माइग्रेशन के दौरान डुप्लिकेट साइड इफेक्ट्स से बच सकते हैं। RFC 9110 308 Permanent Redirect को परिभाषित करता है; MDN बताता है कि जब क्लाइंट नए स्थान पर अनुरोध दोबारा भेजता है, तो उसे मूल मेथड या रिक्वेस्ट बॉडी को नहीं बदलना चाहिए। 301 स्थायी है, लेकिन पुराने क्लाइंट्स में गैर-GET अनुरोधों के लिए कंपैटिबिलिटी अंतर होते हैं और वे मेथड को बदल सकते हैं।
इंटरव्यूअर क्या जांच रहा है
इंटरव्यूअर चाहता है कि आप स्थायी और अस्थायी माइग्रेशन को अलग करें, और फिर पूछें कि क्या मेथड और बॉडी का संरक्षण आवश्यक है। एक मजबूत उत्तर 301, 302, 307 और 308 की तुलना करता है, यह बताता है कि साइड-इफेक्ट वाला POST यह अनुमान लगाने वाले क्लाइंट पर निर्भर क्यों नहीं हो सकता कि पुनः प्रयास कैसे किया जाए, और इसमें idempotency keys, ऑथेंटिकेशन, टाइमआउट और रोलबैक शामिल हैं।
वे आपसे Location की ट्रस्ट बाउंड्री, क्रॉस-ओरिजिन क्रेडेंशियल्स, कैश प्रोपेगेशन, SDK रीडायरेक्ट सीमाएं और उन क्लाइंट्स पर विचार करने की भी अपेक्षा करते हैं जो 308 का समर्थन नहीं करते हैं। माइग्रेशन टेस्ट प्लान के बिना केवल यह रट लेना कि "308 का मतलब 301 प्लस POST प्रिजर्वेशन है", अधूरा है।
पहले पूछे जाने वाले स्पष्टीकरण
स्थायित्व और दायरा
पुष्टि करें कि नया URL स्थिर है या नहीं और क्या यह माइग्रेशन किसी एक रिसोर्स, API प्रीफिक्स या किसी अलग ओरिजिन को कवर करता है। यदि टारगेट अभी भी बदल सकता है, तो क्लाइंट्स और मध्यवर्ती सिस्टमों को समय से पहले स्थायी कैश सेमेंटिक्स सिखाने के बजाय अस्थायी कदम व्यक्त करने के लिए 307 का उपयोग करें।
क्लाइंट क्षमता और साइड इफेक्ट्स
ब्राउज़र, मोबाइल वर्ज़न, SDK, कतार कंज्यूमर्स और पार्टनर्स की सूची बनाएं। पूछें कि क्या POST कोई ऑर्डर बनाता है, पैसे काटता है, या कोई मैसेज भेजता है, और क्या कॉलर idempotency key भेजते हैं। इस प्रमाण के बिना कि रीप्ले सुरक्षित है, रीडायरेक्ट कोई बिना शर्त पुनः प्रयास का निर्देश नहीं है।
क्रेडेंशियल्स, कैश और रोलबैक
दोनों होस्ट्स के लिए ऑथेंटिकेशन स्कोप, CORS, प्रॉक्सी और CDN व्यवहार की पुष्टि करें। पूछें कि क्या पुराना एंडपॉइंट सेवा देना जारी रख सकता है और क्या रोलबैक का अर्थ रीडायरेक्ट हटाना, रूटिंग बदलना, या पुराने हैंडलर को पुनर्स्थापित करना है।
30-सेकंड का उत्तर
"मैं पहले पुष्टि करूँगा कि क्या यह बदलाव स्थायी है और प्रत्येक क्लाइंट का इन्वेंट्री लूँगा। ऐसे स्थायी बदलाव के लिए जिसमें POST मेथड और बॉडी को संरक्षित रखना आवश्यक है, मैं 308 का उपयोग करूँगा; अस्थायी बदलाव के लिए 307 का उपयोग होता है। 301 पुराने क्लाइंट्स में गैर-GET सेमेंटिक्स को संरक्षित करने के लिए एक सख्त अनुबंध नहीं है। मैं शुरू में पुराने एंडपॉइंट को नए हैंडलर पर प्रॉक्सी करूँगा, प्रत्येक साइड इफेक्ट के लिए एक ही idempotency key का पुन: उपयोग करूँगा, और Location होस्ट व क्रेडेंशियल फ़ॉरवर्डिंग को प्रतिबंधित करूँगा। कैनरी के दौरान मैं 3xx फॉलो रेट, डुप्लिकेट क्रिएशन, 4xx/5xx, बॉडी साइज़ और SDK वर्ज़न को ट्रैक करूँगा। यदि सिग्नल्स खराब होते हैं, तो मैं 308 भेजना बंद कर दूँगा और पुराने एंडपॉइंट को सेवा देने में सक्षम रखूँगा।"
चरण-दर-चरण विस्तृत विवरण
चरण 1: स्टेटस कोड का सटीक चयन करें
308 का अर्थ स्थायी स्थानांतरण है और यह अनुरोध मेथड और बॉडी को सुरक्षित रखता है; 307 अस्थायी है और यह भी इन्हें सुरक्षित रखता है। 301 स्थायी है, लेकिन सभी पुराने क्लाइंट POST जैसे मेथड को सुरक्षित नहीं रखते हैं, इसलिए यह POST-माइग्रेशन का सख्त अनुबंध नहीं है। 302 को भी यह गारंटी नहीं देनी चाहिए।
चरण 2: रीप्ले को प्राथमिक बाधा मानें
चूंकि 308 क्लाइंट से पूरी बॉडी दोबारा सबमिट करवा सकता है, इसलिए दोनों एंडपॉइंट्स को एक ही idempotency key द्वारा समान व्यावसायिक कमांड को पहचानना होगा। साइड इफेक्ट निष्पादित करने से पहले, सर्वर अनुरोध डाइजेस्ट के विरुद्ध कुंजी को मान्य करता है; अलग-अलग मापदंडों वाली समान कुंजी दूसरे ऑर्डर के बजाय एक संघर्ष (conflict) बन जाती है। टाइमआउट के बाद भी क्लाइंट अपने पुनः प्रयास बजट का पालन करता है और उसे हमेशा के लिए 308 का पालन नहीं करना चाहिए।
चरण 3: चरणों में रिलीज़ करें और निरीक्षण करें
पुराने पते को एक ऑब्जर्वेबल प्रॉक्सी या 308 प्रतिक्रिया के माध्यम से रूट करने से पहले नए पते को सीधे चालू करें। SDK वर्ज़न, स्रोत ओरिजिन और मेथड द्वारा कैनरी रिलीज़ करें। रीडायरेक्ट-चेन की लंबाई, फॉलो विफलताएं, डुप्लिकेट साइड इफेक्ट्स, टारगेट लेटेंसी, ऑथेंटिकेशन विफलताएं और बॉडी साइज़ रिकॉर्ड करें। जो क्लाइंट 308 का समर्थन नहीं करते हैं, उनके लिए चुपचाप 301 पर स्विच करने और समान व्यवहार मान लेने के बजाय एक अल्पकालिक सर्वर-साइड प्रॉक्सी बनाए रखें।
चरण 4: सुरक्षा, कैशिंग और रोलबैक को संभालें
Location केवल अनुमति-सूचीबद्ध (allow-listed) टारगेट की ओर संकेत कर सकता है। क्रॉस-ओरिजिन हॉप से पहले कुकीज़, Authorization और CORS का पुनर्मूल्यांकन करें ताकि क्रेडेंशियल किसी अविश्वसनीय होस्ट तक न पहुंचें। सत्यापन के दौरान कम समय से शुरुआत करके और धीरे-धीरे इसे बढ़ाते हुए CDN और क्लाइंट कैश विंडो को स्पष्ट करें। रोलबैक पर, नए रीडायरेक्ट जारी करना बंद करें और पुराने एंडपॉइंट को समान idempotency keys स्वीकार करने दें; नए एंडपॉइंट पर पहले से लिखे गए परिणामों को केवल रूट वापस बदलकर "पूर्ववत (undo)" नहीं किया जा सकता है।
एक उच्च गुणवत्ता वाला नमूना उत्तर
मैं इसे केवल नंबर चुनने के अभ्यास के रूप में नहीं, बल्कि एक प्रोटोकॉल और माइग्रेशन प्रश्न के रूप में लूँगा। एक स्थायी बदलाव के लिए जहाँ POST मेथड और बॉडी को संरक्षित किया जाना चाहिए, मैं 308 चुनता हूँ; अस्थायी ट्रैफ़िक शिफ्टिंग के लिए, मैं 307 चुनता हूँ। 301 कई पेज URL माइग्रेशन के लिए उपयुक्त है, लेकिन यह गैर-GET API के लिए आवश्यक सख्त मेथड-संरक्षण की गारंटी नहीं देता है।
रोलआउट से पहले, दोनों URL समान ऑथेंटिकेशन, अनुरोध सत्यापन और idempotency-key अनुबंध का समर्थन करते हैं। पुराना एंडपॉइंट पहले पूरे लॉग के साथ नए हैंडलर को प्रॉक्सी करता है, और समान कुंजी और अनुरोध डाइजेस्ट केवल एक साइड इफेक्ट उत्पन्न कर सकते हैं। इसके बाद मैं क्लाइंट वर्ज़न के अनुसार 308 का कैनरी परीक्षण करता हूँ, टारगेट होस्ट को प्रतिबंधित करता हूँ, क्रॉस-ओरिजिन क्रेडेंशियल्स की पुन: जांच करता हूँ, और CDN, SDK तथा कतार कंज्यूमर व्यवहार को सत्यापित करता हूँ।
मैं रीडायरेक्ट फॉलो रेट, चेन की लंबाई, डुप्लिकेट निर्माण, टारगेट त्रुटियों, ऑथेंटिकेशन विफलताओं और बॉडी साइज़ की निगरानी करता हूँ। यदि कोई पुराना क्लाइंट 308 को नहीं समझता है, तो मैं चुपचाप 301 पर डाउनग्रेड करने के बजाय पुराने एंडपॉइंट प्रॉक्सी को बनाए रखता हूँ। किसी घटना के दौरान मैं 308 को रोकता हूँ, पुराने एंडपॉइंट और idempotency रिकॉर्ड को सुरक्षित रखता हूँ, रूटिंग को पुनर्स्थापित करता हूँ, और अनुरोध ID द्वारा पूर्ण व्यावसायिक परिणामों का मिलान करता हूँ।
सामान्य गलतियाँ
- प्रत्येक बदलाव के लिए 301 लौटाना → पुराने क्लाइंट POST को किसी अन्य मेथड में बदल सकते हैं या बॉडी को छोड़ सकते हैं → स्थायी API बदलाव के लिए 308 का उपयोग करें जिसमें संरक्षण की आवश्यकता हो, फिर क्लाइंट्स को सत्यापित करें।
- 308 देखने के बाद साइड इफेक्ट को फिर से निष्पादित करना → रीडायरेक्ट, टाइमआउट और क्लाइंट पुनः प्रयास एक निर्माण अनुरोध को कई गुना बढ़ा सकते हैं → idempotency key, अनुरोध डाइजेस्ट और एक सीमित पुनः प्रयास बजट का उपयोग करें।
- 307 को स्थायी मानना → एक अस्थायी स्थिति कैश या SDK कॉन्फ़िगरेशन में लंबे समय तक बनी रह सकती है, जिससे रोलबैक कठिन हो जाता है → अस्थायी बदलाव के लिए 307 का उपयोग करें और स्थिरीकरण के बाद ही 308 पर निर्णय लें।
- क्रॉस-ओरिजिन Location जोखिम को अनदेखा करना → कुकीज़ या Authorization किसी अविश्वसनीय टारगेट तक पहुंच सकते हैं → अनुमति-सूची, क्रेडेंशियल नीति और CORS को एक साथ मान्य करें।
- केवल 3xx संख्या देखना → पुराने SDK फॉलो विफलताएं और डुप्लिकेट राइट्स अदृश्य रहते हैं → क्लाइंट वर्ज़न के अनुसार फॉलो रेट, त्रुटियों और साइड-इफेक्ट परिणामों को जोड़कर देखें।
फॉलो-अप प्रश्न
फॉलो-अप 1: पुराने URL से 200 लौटाकर बॉडी में नए URL का उल्लेख क्यों न करें?
यह सामान्य क्लाइंट्स, कैश या SDK को स्वचालित रूप से माइग्रेट करने की अनुमति नहीं देता है, और यह व्यक्त नहीं करता है कि रिसोर्स स्थायी रूप से स्थानांतरित हो गया है। ट्रांज़िशन के दौरान एक सर्वर-साइड प्रॉक्सी बना रह सकता है, लेकिन माइग्रेशन अनुबंध को अभी भी एक स्पष्ट स्थिति और Location की आवश्यकता होती है, जबकि यह रिकॉर्ड किया जाता है कि क्या कॉलर्स ने वास्तव में स्विच किया है।
फॉलो-अप 2: क्या 308 Authorization को बिना किसी बदलाव के नए होस्ट पर अग्रेषित कर सकता है?
डिफ़ॉल्ट रूप से नहीं। पहले यह स्थापित करें कि दोनों होस्ट एक विश्वसनीय सीमा साझा करते हैं; अन्यथा क्लाइंट से टारगेट होस्ट के लिए क्रेडेंशियल प्राप्त करवाएं या स्पष्ट रूप से भेजने को कहें। ओपन रीडायरेक्ट और क्रेडेंशियल लीकेज से बचने के लिए सर्वर को उपयोगकर्ता-नियंत्रित Location मानों को अस्वीकार करना चाहिए।
फॉलो-अप 3: क्या होगा यदि कोई पुराना क्लाइंट 308 का बिल्कुल भी समर्थन नहीं करता है?
पुराने एंडपॉइंट के लिए सर्वर-साइड प्रॉक्सी बनाए रखें या पुराने वर्ज़न के समाप्त होने तक ज्ञात क्लाइंट क्षमता के आधार पर एक कंपैटिबिलिटी रिस्पॉन्स लौटाएं। प्रॉक्सी को अनुरोध idempotency key का पुन: उपयोग करना चाहिए और इसकी एक रिटायरमेंट तिथि होनी चाहिए; आप बिना प्रमाण के यह दावा नहीं कर सकते कि प्रत्येक क्लाइंट 308 को 301 की तरह मानेगा।
फॉलो-अप 4: क्या रोलबैक का मतलब सिर्फ 308 को वापस 200 में बदलना है?
नए एंडपॉइंट द्वारा पहले से लिखे गए ऑर्डर, इवेंट और ऑडिट रिकॉर्ड का मिलान भी करें। नए रीडायरेक्ट रोकें और पुराने एंट्री पॉइंट को पुनर्स्थापित करें, फिर दोनों पाथ्स से समान सोर्स ऑफ ट्रुथ को पढ़वाएं ताकि राइट्स विभाजित या डुप्लिकेट न हों। रूटिंग बहाल होने के बाद अनुरोध ID और idempotency key द्वारा पूर्ण साइड इफेक्ट्स को सत्यापित करें।