1. प्रॉम्प्ट और यूज़ केस
PATCH /profiles/42 वर्षों से प्रोडक्शन में है। सफलता पर, यह एक निश्चित बॉडी के साथ 200 OK लौटाता है: { "success": true }। एक वेब ऐप, मोबाइल ऐप्स, थर्ड-पार्टी सॉफ़्टवेयर डेवलपमेंट किट्स (SDKs), और ऑटोमेशन जॉब्स सभी इसे कॉल करते हैं। बॉडी में कोई व्यावसायिक डेटा नहीं होता है, इसलिए टीम इसके बजाय 204 No Content लौटाना चाहती है।
स्टेटस लाइन बदलना आसान हिस्सा है। एक पुराना क्लाइंट प्रत्येक 2xx रिस्पॉन्स के लिए response.json() को कॉल कर सकता है, एक गेटवे बॉडी से किसी फ़ील्ड को निकाल सकता है, और एक डैशबोर्ड केवल 200 को ही सफलता मान सकता है। माइग्रेशन को पुराने और नए क्लाइंट्स को एक साथ काम करने की अनुमति देनी चाहिए और किसी कंपैटिबिलिटी समस्या के फैलने से पहले एक तेज़ सर्वर-साइड रोलबैक प्रदान करना चाहिए।
2. इंटरव्यूअर क्या टेस्ट कर रहा है
- क्या आप स्टेटस परिवर्तन को एक-लाइन सर्वर एडिट के बजाय रिस्पॉन्स-कॉन्ट्रैक्ट माइग्रेशन के रूप में देखते हैं।
- क्या आप ब्राउज़र्स, मोबाइल ऐप्स, SDKs, प्रॉक्सीज़, मॉनिटर्स, और रिट्राई मिडलवेयर को वास्तविक कंज्यूमर्स के रूप में सूचीबद्ध करते हैं।
- क्या आप वर्ज़निंग या
Preferनेगोशिएशन के माध्यम से 200 और 204 को एक साथ चला सकते हैं। - क्या आप रोलआउट मेट्रिक्स, स्टॉप कंडीशन्स, और ऐसे सर्वर-साइड रोलबैक को परिभाषित करते हैं जिसमें क्लाइंट डाउनग्रेड की आवश्यकता न हो।
- क्या आप जानते हैं कि एक 204 रिस्पॉन्स अपने हेडर सेक्शन के बाद समाप्त हो जाता है और इसमें कंटेंट या ट्रेलर्स नहीं हो सकते।
3. माइग्रेशन से पहले उत्तर देने योग्य प्रश्न
- कौन से क्लाइंट हमेशा JSON पार्स करते हैं, और कौन से केवल
response.okया 2xx क्लास का निरीक्षण करते हैं? - क्या सक्सेस ऑब्जेक्ट वास्तव में अपठित (unread) है, जिसमें लॉग कलेक्टर्स, गेटवे स्क्रिप्ट्स और जनरेट किए गए SDK रिटर्न टाइप्स शामिल हैं?
- क्या क्लाइंट्स स्वचालित रूप से पुनः प्रयास (retry) कर सकते हैं, जिससे एक सफल राइट के बाद पार्स एरर आने पर वह डुप्लिकेट रिक्वेस्ट बन जाए?
- क्या प्रत्येक क्लाइंट को अपग्रेड किया जा सकता है, या दोनों कॉन्ट्रैक्ट्स को लंबे समय तक उपलब्ध रखना होगा?
- ETag, रेट-लिमिट फ़ील्ड्स और ट्रेस आइडेंटिफ़ायर्स जैसे कौन से हेडर्स बने रहने चाहिए?
4. 30-सेकंड का उत्तर फ़्रेमवर्क
मैं पहले एक कंज्यूमर इन्वेंट्री बनाऊँगा और 200 JSON बॉडी पर प्रत्येक निर्भरता को खोजने के लिए कॉन्ट्रैक्ट टेस्ट्स का उपयोग करुँगा। माइग्रेशन के दौरान, 200 डिफ़ॉल्ट बना रहेगा। कंपैटिबल क्लाइंट्स एक नए API वर्ज़न या Prefer: return=minimal के माध्यम से मिनिमल रिस्पॉन्स का विकल्प चुनते हैं; जब सर्वर इसे स्वीकार करता है, तो यह 204 लौटाता है और Preference-Applied रिपोर्ट करता है। मैं आंतरिक ट्रैफ़िक से लेकर ज्ञात कम जोखिम वाले क्लाइंट वर्ज़न्स तक रोलआउट करुँगा, जिसमें पार्स विफलताओं, डुप्लिकेट राइट्स, रिट्राईज़, और प्रति-क्लाइंट सफलता की निगरानी की जाएगी। रोलबैक केवल 200 पर वापस जाने वाला सर्वर स्विच है क्योंकि माइग्रेशन पूरा होने तक JSON सीरियलाइज़ेशन पाथ बरकरार रहता है।
5. चरणबद्ध माइग्रेशन योजना
चरण 1: एक क्लाइंट कैपेबिलिटी इन्वेंट्री बनाएँ
प्रत्येक कॉलर के लिए, उसके ओनर, वर्ज़न, HTTP लाइब्रेरी, सक्सेस चेक, रिस्पॉन्स पार्सर और रिट्राई पॉलिसी को रिकॉर्ड करें। बिना शर्त response.json(), सटीक status === 200 तुलनाओं, जनरेट किए गए SDK रिटर्न टाइप्स, और body.success के गेटवे रीड्स की तलाश करें। अज्ञात या बिना वर्ज़न वाले कॉलर्स 200 पर बने रहते हैं। कंपैटिबिलिटी का कोई प्रमाण न होने का मतलब कोई 204 रोलआउट नहीं है।
चरण 2: क्लाइंट्स को दोनों सक्सेस कॉन्ट्रैक्ट्स स्वीकार करने लायक बनाएँ
पहले क्लाइंट सपोर्ट रिलीज़ करें। एक कंपैटिबल क्लाइंट सहमत 2xx रिस्पॉन्स स्वीकार करता है, पार्स करने से पहले 204 या खाली बॉडी की जांच करता है, और रिक्वेस्ट की सफलता को JSON डिकोडिंग से अलग करता है। कॉन्ट्रैक्ट टेस्ट्स इसे 200 + JSON और 204 + empty body दोनों प्रदान करते हैं। इस क्रम को उलटने से एक सफल राइट के क्लाइंट-विज़िबल पार्स विफलता और फिर डुप्लिकेट रिट्राई में बदलने का जोखिम होता है।
चरण 3: चुनें कि दोनों कॉन्ट्रैक्ट्स एक साथ कैसे मौजूद रहेंगे
जानबूझकर किए गए ब्रेकिंग चेंज के लिए, एक नया API वर्ज़न हमेशा 204 लौटा सकता है जबकि पुराना वर्ज़न 200 बनाए रखता है। यदि रूट और ऑपरेशन समान रहते हैं, तो RFC 7240 प्राथमिकता नेगोशिएशन (preference negotiation) एक अन्य विकल्प है: कंपैटिबल क्लाइंट्स Prefer: return=minimal भेजते हैं; सर्वर इसे 204 और Preference-Applied: return=minimal के साथ पूरा कर सकता है। जिन कॉलर्स को रिप्रेजेंटेशन की आवश्यकता होती है वे Prefer: return=representation भेजते हैं या डिफ़ॉल्ट 200 व्यवहार बनाए रखते हैं। यदि रिस्पॉन्स कैशेबल है, तो Vary: Prefer को सही ढंग से घोषित करें।
चरण 4: रैंडम रिक्वेस्ट के बजाय क्लाइंट के अनुसार रोल आउट करें
व्यवहार को पहले टेस्ट एनवायरनमेंट्स और आंतरिक कॉलर्स में सक्षम करें, फिर केवल उन्हीं क्लाइंट वर्ज़न्स तक विस्तारित करें जो कंपैटिबल माने जाते हैं। प्रत्येक क्लाइंट या खाते को एक स्थिर कोहॉर्ट में रखें ताकि वह 200 और 204 के बीच बदलता न रहे। विस्तार करने से पहले प्रत्येक चरण में एक पूर्ण व्यावसायिक चक्र का अवलोकन करें; स्वच्छ HTTP मेट्रिक्स की एक छोटी अवधि पर्याप्त नहीं है।
चरण 5: प्रोटोकॉल परिवर्तन से होने वाली विफलताओं का निरीक्षण करें
सर्वर पर, क्लाइंट वर्ज़न के अनुसार 200, 204, 5xx, और रिट्राई काउंट्स को विभाजित करें। क्लाइंट्स पर, खाली-बॉडी पार्स विफलताओं, सफल रिक्वेस्ट के बाद दिखाए गए एरर UI, और डुप्लिकेट सबमिशन को रिकॉर्ड करें। पूरे हुए राइट्स की तुलना रिक्वेस्ट रिट्राईज़ से करें, विशेष रूप से नॉन-इडेम्पोटेंट ऑपरेशन्स के लिए। अलर्ट्स को क्लाइंट वर्ज़न और रोलआउट कोहॉर्ट की पहचान करनी चाहिए; कुल 2xx दरें कंपैटिबिलिटी विफलताओं को छुपा देती हैं।
चरण 6: तत्काल रोलबैक सुरक्षित रखें और माइग्रेशन को पूरा करें
माइग्रेशन के दौरान मूल JSON सीरियलाइज़ेशन पाथ को सर्वर स्विच के पीछे रखें। यदि कोई स्टॉप कंडीशन सक्रिय होती है, तो विश्व स्तर पर 200 पुनर्स्थापित करें; डुअल-कंपैटिबल क्लाइंट्स बिना डाउनग्रेड के काम करते रहते हैं। पुराने पाथ को केवल तभी हटाएं जब प्रत्येक समर्थित क्लाइंट न्यूनतम कंपैटिबल वर्ज़न से ऊपर हो, एक सहमत अवलोकन विंडो के लिए पुराना ट्रैफ़िक अनुपस्थित हो, और SDK, प्रॉक्सी और कॉन्ट्रैक्ट सुइट्स अभी भी पास होते हों।
6. उच्च-गुणवत्ता वाला नमूना उत्तर
मैं इसे रिस्पॉन्स-कॉन्ट्रैक्ट माइग्रेशन के रूप में मानूँगा। सबसे पहले मैं प्रत्येक कंज्यूमर की सूची बनाऊँगा और ऐसे कोड का पता लगाऊँगा जो हमेशा JSON पार्स करता है, विशेष रूप से 200 की जांच करता है, याbody.successपढ़ता है। सर्वर के व्यवहार को बदलने से पहले मैं ऐसे क्लाइंट्स रिलीज़ करुँगा जो 200 JSON और बिना बॉडी वाले 204 दोनों को स्वीकार करते हैं। सर्वर 200 को डिफ़ॉल्ट के रूप में रखता है; कंपैटिबल क्लाइंट्स एक API वर्ज़न याPrefer: return=minimalके माध्यम से 204 का चयन करते हैं, जिसकी पुष्टिPreference-Appliedद्वारा की जाती है। रोलआउट क्लाइंट वर्ज़न के अनुसार आगे बढ़ता है, जिसमें पार्स विफलताएं, रिट्राईज़, और डुप्लिकेट राइट्स प्राथमिक संकेत होते हैं। 200 सीरियलाइज़ेशन पाथ तब तक उपलब्ध रहता है जब तक कि सभी समर्थित क्लाइंट्स माइग्रेट नहीं हो जाते, इसलिए रोलबैक क्लाइंट रिलीज़ के बजाय एक सर्वर-साइड स्विच होता है।
7. सामान्य गलतियाँ
- 200 को सीधे 204 में बदलना → खाली बॉडी को पार्स करते समय पुराने क्लाइंट्स विफल हो जाते हैं → 204 सक्षम करने से पहले डुअल-कंपैटिबल क्लाइंट्स रिलीज़ करें।
- केवल HTTP एरर दरों पर नज़र रखना → 204 अभी भी एक सफल रिस्पॉन्स है, इसलिए पार्स विफलताएं सर्वर 5xx के रूप में दिखाई नहीं देती हैं → क्लाइंट पार्सिंग, रिट्राई और डुप्लिकेट-राइट मेट्रिक्स जोड़ें।
- प्रति रिक्वेस्ट रोलआउट को रैंडमाइज़ करना → एक क्लाइंट को अस्थिर कॉन्ट्रैक्ट प्राप्त होता है → क्लाइंट वर्ज़न या किसी अन्य स्थिर पहचान द्वारा कोहॉर्ट बनाएं।
- परिणाम की रिपोर्ट किए बिना
Preferस्वीकार करना → क्लाइंट यह नहीं बता सकता कि प्राथमिकता का सम्मान किया गया था या नहीं →Preference-Appliedलौटाएं और डिफ़ॉल्ट व्यवहार को परिभाषित करें। - JSON सीरियलाइज़ेशन को तुरंत हटाना → रोलबैक के लिए कोड रिलीज़ की आवश्यकता होती है → माइग्रेशन विंडो बंद होने तक पुराने पाथ को बनाए रखें।
- स्वचालित रिट्राई व्यवहार को अनदेखा करना → एक पार्स एरर सफल राइट को विफलता के रूप में छुपाता है → इडेम्पोटेन्सी कीज़, रिट्राई मिडलवेयर, और डुप्लिकेट-सबमिशन मेट्रिक्स को सत्यापित करें।
8. फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: सभी क्लाइंट्स को एक साथ क्यों न बदलें?
सर्वर यह साबित कर सकता है कि राइट सफल रहा, लेकिन यह साबित नहीं कर सकता कि प्रत्येक डिप्लॉयड क्लाइंट 204 बॉडी को सही ढंग से संभालता है। एक पुराना वर्ज़न जो हमेशा JSON पार्स करता है, वह प्रोटोकॉल की सफलता को यूज़र-विज़िबल विफलता में बदल देता है। पहले क्लाइंट कंपैटिबिलिटी, उसके बाद वर्ज़न-स्कोप्ड रोलआउट, विफलता की सीमा को देखने योग्य (observable) बनाए रखता है।
फॉलो-अप 2: आपको वर्ज़निंग बनाम Prefer का चयन कब करना चाहिए?
एक नया वर्ज़न एक स्थायी कॉन्ट्रैक्ट ब्रेक के लिए उपयुक्त होता है और इसे समझना आसान होता है, लेकिन यह वर्ज़न-लाइफ़साइकल का काम बढ़ाता है। Prefer एक ऐसे ऑपरेशन के लिए उपयुक्त है जहाँ लौटाया गया रिप्रेजेंटेशन और मिनिमल रिस्पॉन्स दोनों मान्य हैं। चूँकि सर्वर किसी प्राथमिकता को अनदेखा कर सकता है, क्लाइंट को एक प्रलेखित डिफ़ॉल्ट की आवश्यकता होती है और उसे Preference-Applied का निरीक्षण करना चाहिए। दोनों ही User-Agent स्ट्रिंग्स से अनुमान लगाने की तुलना में अधिक विश्वसनीय हैं।
फॉलो-अप 3: एक 204 रिस्पॉन्स क्या जानकारी बनाए रख सकता है?
यह ETag, ट्रेस आइडेंटिफ़ायर्स और रेट-लिमिट फ़ील्ड्स जैसे हेडर्स को बनाए रख सकता है। इसमें मैसेज कंटेंट या ट्रेलर्स नहीं हो सकते हैं। इसलिए एक क्लाइंट को "कोई JSON नहीं" और "कोई मेटाडेटा नहीं" को अलग-अलग प्रश्नों के रूप में देखना चाहिए।
फॉलो-अप 4: 200 कंपैटिबिलिटी पाथ को हटाना कब सुरक्षित है?
सभी समर्थित क्लाइंट्स को डुअल-रिस्पॉन्स हैंडलिंग रिलीज़ कर देनी चाहिए, टेलीमेट्री में कोई पुराना-वर्ज़न ट्रैफ़िक नहीं दिखना चाहिए, और SDK, प्रॉक्सी, ऑटोमेशन और रोलबैक टेस्ट्स पास होने चाहिए। केवल ऐप-स्टोर रिलीज़ ही पर्याप्त नहीं है क्योंकि यूज़र्स लंबे समय तक पुराने वर्ज़न्स पर बने रह सकते हैं।