बैकएंड इंटरव्यू: बिना क्लाइंट्स को तोड़े पब्लिक API को कैसे इवॉल्व करें?

प्रॉम्प्ट और यह कब लागू होता है

एक पब्लिक Orders REST API का उपयोग पहले से ही 600 थर्ड-पार्टी इंटीग्रेशन और कई ऐसे मोबाइल ऐप्स द्वारा किया जा रहा है जिन्हें अपग्रेड करने के लिए बाध्य नहीं किया जा सकता। मौजूदा GET /v1/orders हर ऑर्डर को एक ही रिस्पॉन्स में लौटाता है। प्रत्येक ऑर्डर में एक customer_name स्ट्रिंग होती है, और status वर्तमान में केवल pending या paid लौटाता है। अगले रिलीज़ में कस्टमर डेटा को एक स्ट्रक्चर्ड ऑब्जेक्ट के रूप में एक्सपोज़ करना, लिस्ट को पेजिनेट करना और refunded स्टेटस पेश करना आवश्यक है।

ये 600 इंटीग्रेशन, वर्तमान फ़ील्ड्स और स्टेटस वैल्यू इंटरव्यू की मान्यताएँ हैं। बाध्यकारी शर्त यह है कि प्रोवाइडर यह नियंत्रित नहीं कर सकता कि हर कंज्यूमर कब अपग्रेड करेगा। सफलता में एक कार्यशील v2, मूल अनुबंध के तहत निरंतर v1 व्यवहार, अवलोकनीय माइग्रेशन, खोजने योग्य डेप्रिकेशन तिथियाँ, और किसी वर्ज़न के प्रॉमिस किए गए अर्थ को बदले बिना विफल रिलीज़ से रिकवरी शामिल है।

यह एक बैकएंड प्रश्न है क्योंकि यह API कॉन्ट्रैक्ट्स, सर्वर-साइड रिप्रेजेंटेशन, रिलीज़ इंजीनियरिंग और कम्पैटिबिलिटी गवर्नेंस का परीक्षण करता है। इसके लिए संपूर्ण ऑर्डर सिस्टम के डिज़ाइन या डेटाबेस-शार्डिंग प्लान की आवश्यकता नहीं है। प्रत्येक बदलाव को वर्गीकृत करने से पहले मौजूदा अनुबंध लिखें। केवल यह कहना कि "URL में v2 डाल दें" यह साबित नहीं करता कि पुराने क्लाइंट सुरक्षित रहेंगे।

{
  "orders": [
    {
      "id": "ord_1",
      "customer_name": "Ada Lovelace",
      "status": "paid"
    }
  ]
}

इंटरव्यूअर क्या मूल्यांकन करते हैं

पहला संकेत यह है कि क्या उम्मीदवार तीन प्रकार की कम्पैटिबिलिटी के बीच अंतर करता है। सोर्स कम्पैटिबिलिटी यह देखती है कि क्या पुराना क्लाइंट कोड अपने SDK को फिर से जनरेट या अपग्रेड करने के बाद भी कंपाइल होता है। वायर कम्पैटिबिलिटी यह देखती है कि क्या पुराना सीरियलाइज़र नए मैसेज को पार्स कर सकता है। सिमेंटिक कम्पैटिबिलिटी यह देखती है कि क्या वही कॉल अभी भी वैसा ही व्यवहार करती है जैसी एक समझदार कंज्यूमर अपेक्षा करेगा। एक अपरिवर्तित फ़ील्ड प्रकार अपने आप सिमेंटिक्स को संरक्षित नहीं करता है। "हर ऑर्डर लौटाएं" को चुपचाप बदलकर "पहले 100 ऑर्डर लौटाएं" करने से भी वैध JSON ही बनता है, लेकिन पुराने क्लाइंट डेटा खो देते हैं।

दूसरा संकेत अनुबंध-आधारित निर्णय है। एक रटी हुई यूनिवर्सल टेबल हर वास्तविक क्लाइंट के पार्सिंग व्यवहार का प्रतिनिधित्व नहीं कर सकती। एक नया वैकल्पिक रिक्वेस्ट फ़ील्ड, जिसके छूट जाने पर भी पुराना व्यवहार बना रहता है, आमतौर पर v1 में रह सकता है। किसी फ़ील्ड को हटाना, उसका नाम बदलना या उसका प्रकार बदलना v1 को तोड़ देता है। एक अतिरिक्त रिस्पॉन्स फ़ील्ड केवल तभी सुरक्षित जोड़ है जब अनुबंध अज्ञात फ़ील्ड्स की अनुमति देता है और वास्तविक SDK उन्हें अनदेखा करते हैं। एक रिस्पॉन्स enum वैल्यू जोड़ना अतिरिक्त जांच का विषय है: एक ओपन-enum अनुबंध विस्तार की अनुमति दे सकता है, जबकि एक क्लोज्ड enum, जनरेटेड स्ट्रॉन्गली टाइप्ड SDK, या डिफ़ॉल्ट ब्रांच के बिना एग्जॉस्टिव स्विच विफल हो सकता है।

तीसरा संकेत वर्ज़न, इम्प्लीमेंटेशन और लाइफ़साइकिल को जोड़ने वाला एक चलने योग्य मार्ग है। एक मजबूत उत्तर v1 प्रेजेंटेशन लेयर को बनाए रखता है, अलग-अलग v1 और v2 रिस्पॉन्स तैयार करने के लिए शेयर्ड डोमेन लॉजिक का उपयोग करता है, रिलीज़ से पहले कॉन्ट्रैक्ट-डिफ़ और पुराने SDK टेस्ट चलाता है, उसके बाद कंज्यूमर द्वारा एडॉप्शन, एरर और लेटेंसी मापता है, और अंततः मानकीकृत डेप्रिकेशन सिग्नल्स, एक माइग्रेशन गाइड और स्पष्ट शटडाउन गेट्स के साथ पुराने वर्ज़न को रिटायर करता है। एक वर्ज़न आइडेंटिफ़ायर केवल एक रूटिंग विकल्प है; यह इनमें से कोई भी कार्य स्वचालित रूप से नहीं करता है।

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

• क्या कंज्यूमर्स को नियंत्रित किया जा सकता है? एक ही कंपनी के भीतर तीन सर्विस जो एक साथ रोलआउट का समन्वय कर सकती हैं, वे लंबे समय तक चलने वाले v2 के बिना expand–migrate–contract का उपयोग कर सकती हैं। थर्ड पार्टीज़ और पुराने मोबाइल क्लाइंट्स को एक स्थिर वर्ज़न सीमा और एक पब्लिक लाइफ़साइकिल की आवश्यकता होती है।
• क्या वर्तमान अनुबंध के तहत क्लाइंट्स के लिए अज्ञात फ़ील्ड्स और enum वैल्यूज़ को अनदेखा करना आवश्यक है? यह निर्धारित करता है कि क्या जोड़ा गया रिस्पॉन्स फ़ील्ड या enum वैल्यू v1 में रह सकता है। केवल वैध JSON पर्याप्त नहीं है; OpenAPI अनुबंध, SDK प्रकार और वास्तविक कंज्यूमर व्यवहार की जांच करें।
• लिस्ट कितनी बड़ी है, और यह क्या विश्वसनीयता जोखिम पैदा करती है? यदि सभी ऑर्डर लौटाना अभी भी SLO को पूरा करता है, तो पेजिनेशन केवल v2 में मौजूद हो सकता है। यदि कोई अनबाउंड रिस्पॉन्स पहले से ही उपलब्धता को खतरे में डाल रहा है, तो रेट लिमिट और एक आपातकालीन कम्युनिकेशन पाथ आवश्यक हो सकता है, लेकिन चुपचाप डेटा को ट्रंकेट करना अभी भी एक कम्पैटिबल बदलाव नहीं है।
• क्या API ने पहले से ही कोई वर्ज़न-चयन तंत्र प्रकाशित किया है? जब पाथ वर्ज़न पहले से मौजूद हों तो /v1 और /v2 का उपयोग जारी रखें, या जब वर्ज़न हेडर-आधारित हों तो मौजूदा डेट हेडर बनाए रखें। माइग्रेशन के दौरान मैकेनिज्म बदलने से एक और क्लाइंट बदलाव पैदा होता है।
• क्या प्रोवाइडर प्रत्येक कंज्यूमर की पहचान कर सकता है और उसके ओनर से संपर्क कर सकता है? स्थिर एप्लिकेशन ID, SDK वर्ज़न और ओनर संपर्क सटीक माइग्रेशन ट्रैकिंग को सक्षम करते हैं। अज्ञात ट्रैफ़िक के लिए अधिक रूढ़िवादी रिटायरमेंट गेट्स की आवश्यकता होती है।
• किस कानूनी, संविदात्मक या व्यावसायिक समर्थन अवधि का वादा किया गया था? शटडाउन की तारीख प्रकाशित नीति, ग्राहक दायित्वों, जोखिम और वास्तविक एडॉप्शन से तय होती है। किसी अन्य प्लेटफ़ॉर्म की समर्थन अवधि कोई सार्वभौमिक नियम नहीं है।

30-सेकंड का रिस्पॉन्स फ्रेमवर्क

"मैं सबसे पहले v1 के लिखित अनुबंध और अवलोकनीय व्यवहार को फ़्रीज़ करूँगा, फिर सोर्स, वायर और सिमेंटिक कम्पैटिबिलिटी के आधार पर प्रत्येक प्रस्ताव को वर्गीकृत करूँगा। अपरिवर्तित डिफ़ॉल्ट व्यवहार वाला एक नया वैकल्पिक फ़ील्ड v1 में फिट हो सकता है। एक स्ट्रिंग को ऑब्जेक्ट से बदलना, फ़ील्ड का नाम बदलना और सभी परिणामों वाली लिस्ट को पेजिनेशन में बदलना v2 की मांग करता है। एक नई रिस्पॉन्स enum वैल्यू ओपन-enum नीति और पुराने SDK व्यवहार पर निर्भर करती है। मैं Orders डोमेन लॉजिक को शेयर करूँगा और केवल v1 और v2 प्रेजेंटेशन एडेप्टर रखूँगा। रिलीज़ से पहले, मैं एक OpenAPI डिफ़, पुराने SDK टेस्ट, रिकॉर्डेड-रिक्वेस्ट रीप्ले और एंड-टू-एंड कॉन्ट्रैक्ट टेस्ट चलाऊँगा, फिर ज्ञात कंज्यूमर्स को v2 में ऑप्ट-इन करने की अनुमति दूँगा। मैं कंज्यूमर द्वारा एडॉप्शन और एरर की निगरानी करूँगा, माइग्रेशन, डेप्रिकेशन और शटडाउन तिथियाँ प्रकाशित करूँगा, और v1 को उसके माइग्रेशन और दायित्व गेट्स पास होने के बाद ही रिटायर करूँगा। किसी भी विफलता बिंदु पर, मैं v2 रूट या एडेप्टर को रोलबैक कर सकता हूँ जबकि v1 अपरिवर्तित रहेगा।"

चरण-दर-चरण विस्तृत विश्लेषण

एक कम्पैटिबिलिटी बेसलाइन बनाकर शुरुआत करें। वर्तमान OpenAPI दस्तावेज़, रिलीज़ किए गए SDK, प्रतिनिधि रिक्वेस्ट और रिस्पॉन्स, एरर कोड, ऑर्डरिंग, डिफ़ॉल्ट और लिस्ट व्यवहार को सुरक्षित रखें। गैर-दस्तावेज़ीकृत लेकिन दृश्यमान व्यवहार का भी नमूना लें, क्योंकि कंज्यूमर फ़ील्ड फ़ॉर्मेट, नल हैंडलिंग, ऑर्डरिंग, या एक रिस्पॉन्स में पूरा रिज़ल्ट सेट प्राप्त करने पर निर्भर हो सकते हैं। उसी समय कंज्यूमर ID, वर्ज़न, रिक्वेस्ट वॉल्यूम और ओनर को रिकॉर्ड करें। बाद में, यह "अप्रयुक्त" को "किसी ऐसे व्यक्ति द्वारा उपयोग किया गया जिसे प्रोवाइडर पहचान नहीं सकता" से अलग करता है।

फिर प्रत्येक प्रस्तावित बदलाव को वर्गीकृत करें:

पेजिनेशन को कम आंकना आसान है। Google का कम्पैटिबिलिटी मार्गदर्शन उस API में एक सीमित डिफ़ॉल्ट page_size जोड़ने के जोखिम को इंगित करता है जो पहले हर आइटम लौटाता था: एक पुराना क्लाइंट गलत तरीके से मान सकता है कि पहला रिस्पॉन्स पूरा है। v2 में items, next_page_token, ऑर्डरिंग और टोकन-अमान्यता नियम परिभाषित करें। समर्थन अवधि के दौरान, v1 अपने मूल सिमेंटिक्स को बनाए रखता है जबकि कोटा, रिस्पॉन्स-साइज़ मॉनिटरिंग और माइग्रेशन आउटरीच परिचालन जोखिम को नियंत्रित करते हैं।

इसके बाद, वर्ज़न सीमा तय करें। प्रॉम्प्ट पहले से ही पाथ वर्ज़निंग का उपयोग करता है, इसलिए /v2/orders जोड़ें। उसी पाथ पर User-Agent से वर्ज़न का अनुमान न लगाएं, और v1 को नए सिमेंटिक्स वाले रिप्रेजेंटेशन पर चुपचाप रूट न करें। केवल बाहरी रिप्रेजेंटेशन का वर्ज़न बनाएं। प्रत्येक रिक्वेस्ट को एक ही डोमेन कमांड में पार्स करें, ऑर्डर-क्वेरी और ऑथराइजेशन लॉजिक साझा करें, फिर संबंधित आकार बनाने के लिए V1OrderPresenter या V2OrderPresenter का उपयोग करें। सर्विस को डुप्लिकेट किए बिना सुरक्षा सुधार और व्यावसायिक नियम दोनों वर्ज़नों तक पहुंच सकते हैं।

एक उदाहरण v2 रिस्पॉन्स है:

{
  "orders": [
    {
      "id": "ord_1",
      "customer": {
        "display_name": "Ada Lovelace"
      },
      "status": "paid"
    }
  ],
  "next_page_token": "eyJvcmRlcl9pZCI6Im9yZF8xIn0"
}

चार रिलीज़ गेट्स का उपयोग करें। पहला, पुरानी और नई OpenAPI परिभाषाओं की तुलना करें और v1 फ़ील्ड हटाने, अनिवार्यता में बदलाव, प्रकार में बदलाव और अनपेक्षित नए वैलिडेशन नियमों को अस्वीकार करें। दूसरा, अंतिम सार्वजनिक v1 SDK के साथ निश्चित कॉन्ट्रैक्ट मामलों को कंपाइल और रन करें, जिसमें अज्ञात फ़ील्ड, नल, एरर रिस्पॉन्स और enums शामिल हैं। तीसरा, प्रतिनिधि सैनिटाइज़्ड रिक्वेस्ट्स को रीप्ले करें और पुराने और नए v1 इम्प्लीमेंटेशन के बीच स्टेटस कोड, महत्वपूर्ण फ़ील्ड और ऑर्डरिंग की तुलना करें। चौथा, ज्ञात कंज्यूमर्स के एक छोटे समूह को सैंडबॉक्स या कैनरी वातावरण में v2 में ऑप्ट-इन करने दें और कार्यक्षमता, 4xx, 5xx, लेटेंसी और रिस्पॉन्स साइज़ का निरीक्षण करें। एक स्कीमा डिफ़ संरचनात्मक बदलाव ढूंढ सकता है; यह ऑर्डरिंग, डिफ़ॉल्ट या पेज पूर्णता के बारे में सिमेंटिक दावों की जगह नहीं ले सकता।

माइग्रेशन ऑप्ट-इन के रूप में शुरू होता है। v2 दस्तावेज़, SDK, फ़ील्ड-दर-फ़ील्ड माइग्रेशन टेबल और दोनों वर्ज़नों का समर्थन करने वाला सैंडबॉक्स प्रकाशित करें। प्रत्येक ज्ञात कंज्यूमर को उसका v1 कॉल वॉल्यूम, विफल एंडपॉइंट और लक्षित तिथि दिखाएं। प्रोवाइडर के उदाहरणों और आधिकारिक SDKs को पहले माइग्रेट करें ताकि गाइड में कमियां जल्दी सामने आ सकें। कंज्यूमर द्वारा एडॉप्शन की समीक्षा करें और कुल रिक्वेस्ट्स का अलग से निरीक्षण करें: कम-मात्रा वाला महीने के अंत का समाधान (reconciliation) इंटीग्रेशन कई हेल्थ चेक्स से अधिक महत्वपूर्ण हो सकता है। प्रति वर्ज़न यूनीक एक्टिव कंज्यूमर्स, रिक्वेस्ट वॉल्यूम, 4xx, 5xx, p95 लेटेंसी, पेजिनेशन पूर्णता, पुराने-SDK पार्स विफलताएं, और ऐसे उच्च-जोखिम वाले खातों को ट्रैक करें जिनसे संपर्क किया गया है लेकिन उन्होंने माइग्रेट नहीं किया है।

लाइफ़साइकिल के तीन पलों को अलग करें: माइग्रेशन नीति प्रकाशित करना, API को औपचारिक रूप से डेप्रिकेट करना, और इसे रिस्पॉन्स देना बंद करना। RFC 9745 डेप्रिकेशन तिथि के लिए Deprecation रिस्पॉन्स हेडर और सहायक जानकारी के लिए deprecation लिंक रिलेशन को परिभाषित करता है। Sunset केवल तभी जोड़ें जब प्रोवाइडर रिसोर्स द्वारा रिस्पॉन्स देना बंद करने की योजना बनाता है। डेप्रिकेशन से रिसोर्स का व्यवहार नहीं बदलना चाहिए। ये तारीखें इंटरव्यू के उदाहरण हैं; वास्तविक तिथियों को प्रकाशित नीति का पालन करना चाहिए:

Deprecation: @1803859200
Sunset: Wed, 01 Sep 2027 00:00:00 GMT
Link: <https://api.example.com/migrations/orders-v2>; rel="deprecation"; type="text/html"

v1 को रिटायर करने से पहले, निम्नलिखित सभी की आवश्यकता होती है: समर्थन दायित्व पूरे किए गए हैं; ज्ञात महत्वपूर्ण कंज्यूमर्स माइग्रेट हो चुके हैं या उन्हें स्वीकृत अपवाद मिला है; शेष ट्रैफ़िक स्पष्ट है; माइग्रेशन गाइड और सहायता चैनल काम करते हैं; v2 एरर, लेटेंसी और व्यावसायिक परिणाम गेट्स पास होते हैं; और शटडाउन रिहर्सल को उलटा किया जा सकता है। यदि कोई उच्च-मूल्य वाला ग्राहक अभी भी अटका हुआ है, तो समर्थन बढ़ाएं, एक सीमित कम्पैटिबिलिटी गेटवे प्रदान करें, या अनुबंध का पालन करें। केवल 100% एडॉप्शन प्रदर्शित करने के लिए उस ग्राहक की अनदेखी न करें।

रिलीज़ से पहले रोलबैक परिभाषित करें। v2 रूट और प्रेजेंटेशन एडेप्टर को स्वतंत्र रूप से डिसेबल किया जा सकता है, डोमेन राइट्स बैकवर्ड-कम्पैटिबल रहते हैं, और v1 अपना अंतिम सत्यापित आर्टिफ़ैक्ट रखता है। यदि किसी v2 फ़ील्ड को नए स्टोरेज की आवश्यकता है, तो v2 द्वारा इसे पढ़ने से पहले उस स्टोरेज का विस्तार और बैकफ़िल करें; v2 रिलीज़ में v1 द्वारा आवश्यक डेटा को न हटाएं। v2 को रोलबैक करने का अर्थ इसके इम्प्लीमेंटेशन को रीस्टोर करना है। घटना को छिपाने के लिए "v2" के अर्थ को बदलना अनुबंध का फिर से उल्लंघन करेगा।

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

"मैं अनुबंध परिवर्तनों को रिलीज़ लाइफ़साइकिल से अलग करूँगा। इन क्लाइंट्स को अपग्रेड करने के लिए बाध्य नहीं किया जा सकता, इसलिए मुझे JSON पार्सिंग, पुराने SDK निष्पादन, और समान रिक्वेस्ट के लिए समान अर्थ वाले पूर्ण परिणामों को सुरक्षित रखने की आवश्यकता है।

customer_name को स्ट्रिंग से ऑब्जेक्ट में बदलने से इसका प्रकार बदल जाता है, और इसका नाम बदलना एक 'हटाना-और-जोड़ना' ऑपरेशन है, इसलिए दोनों v2 से संबंधित हैं। GET /orders को डिफ़ॉल्ट रूप से पेजिनेट करने से पुराने क्लाइंट्स के परिणाम छूट जाएंगे, जो कि एक सिमेंटिक ब्रेक है और यह भी v2 का हिस्सा है। मैं यह नहीं मानूँगा कि refunded जोड़ना सुरक्षित है। यदि रिस्पॉन्स enum को ओपन के रूप में प्रलेखित किया गया है और पुराने SDK अज्ञात वैल्यूज़ को बनाए रखते हैं, तो v1 का विस्तार हो सकता है। यदि जनरेट किया गया कोड क्लोज्ड enum का उपयोग करता है या कंज्यूमर्स उस पर एग्जॉस्टिव स्विच करते हैं, तो मैं नए वैल्यू को v2 में रखूँगा या पहले एक सुरक्षित अज्ञात-वैल्यू पाथ स्थापित और परीक्षण करूँगा।

मैं /v1/orders के रिस्पॉन्स और सभी-परिणाम सिमेंटिक्स को संरक्षित करूँगा, फिर एक स्ट्रक्चर्ड कस्टमर ऑब्जेक्ट, कर्सर और पेज नियमों के साथ /v2/orders बनाऊँगा। दोनों वर्ज़न क्वेरींग, ऑथराइजेशन और ऑर्डर-स्टेट लॉजिक साझा करते हैं; केवल रिक्वेस्ट पार्सिंग और रिस्पॉन्स प्रेजेंटेशन भिन्न होते हैं। मर्ज करने से पहले, मैं OpenAPI परिभाषाओं की तुलना करूँगा, अंतिम v1 SDK के माध्यम से कॉन्ट्रैक्ट टेस्ट चलाऊँगा, और स्टेटस कोड, ऑर्डरिंग, डिफ़ॉल्ट और पूर्णता की जांच के लिए सैनिटाइज़्ड रिक्वेस्ट्स को रीप्ले करूँगा। आंतरिक SDKs और ज्ञात इंटीग्रेशन का एक छोटा सेट पहले v2 में ऑप्ट-इन करेगा। किसी रिग्रेशन की स्थिति में v2 रूट डिसेबल हो जाएगा जबकि v1 बिना किसी बदलाव के जारी रहेगा।

माइग्रेशन के दौरान, मैं एप्लिकेशन ID द्वारा एक्टिव कंज्यूमर्स को मापूँगा, कुल ट्रैफ़िक को एक सहायक सिग्नल के रूप में उपयोग करूँगा, और वर्ज़न एडॉप्शन, पार्स विफलताओं, 4xx, 5xx, लेटेंसी, पेजिनेशन पूर्णता और महत्वपूर्ण खातों को ट्रैक करूँगा। गाइड में फ़ील्ड मैपिंग, पेजिनेशन लूप, enum फ़ॉलबैक और एक टेस्ट वातावरण शामिल है। औपचारिक डेप्रिकेशन रिस्पॉन्स हेडर और माइग्रेशन लिंक के माध्यम से खोजने योग्य है; शटडाउन की एक अलग घोषित तिथि होती है। मैं v1 को केवल समर्थन दायित्वों, महत्वपूर्ण कंज्यूमर्स, शेष ट्रैफ़िक और v2 SLOs द्वारा अपने गेट्स पास करने के बाद और एक प्रतिवर्ती रिहर्सल के बाद ही रिटायर करूँगा। यह वर्ज़न आइडेंटिफ़ायर, कम्पैटिबल इम्प्लीमेंटेशन, माइग्रेशन साक्ष्य और रिटायरमेंट को एक टेस्टेबल योजना बनाता है।"

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

• केवल "URL में /v2 डालें" उत्तर देना → यह न तो यह पहचानता है कि कौन ब्रेक होता है और न ही माइग्रेशन और शटडाउन गेट्स को → v1 को बेसलाइन करें, फिर सोर्स, वायर और सिमेंटिक कम्पैटिबिलिटी में हर बदलाव को वर्गीकृत करें।
• यह मान लेना कि प्रत्येक रिस्पॉन्स जोड़ कम्पैटिबल है → स्ट्रिक्ट डिसीरियलाइज़र, क्लोज्ड enums और एग्जॉस्टिव स्विच अभी भी विफल हो सकते हैं → पब्लिक अनुबंध और जनरेट किए गए SDKs की जांच करें, फिर वास्तविक पुराने-वर्ज़न टेस्ट चलाएं।
• v1 को स्वचालित रूप से v2 पर रीडायरेक्ट करना → एक वर्ज़न आइडेंटिफ़ायर दो सिमेंटिक्स का प्रतिनिधित्व करने लगता है, इसलिए क्लाइंट चुन नहीं सकते या रोलबैक नहीं कर सकते → एक स्थिर v1 प्रेजेंटेशन बनाए रखें और स्पष्ट v2 चयन की मांग करें।
• v1 और v2 के लिए पूरी सर्विस की प्रतिलिपि बनाना → सुरक्षा सुधार और व्यावसायिक नियम अलग-थलग पड़ जाते हैं जबकि दोहरे वर्ज़न की लागत बढ़ती है → डोमेन लॉजिक साझा करें और केवल उस पार्सिंग और प्रेजेंटेशन को अलग करें जो वास्तव में भिन्न है।
• घोषित तिथि आने पर v1 को बंद कर देना → अज्ञात लॉन्ग-टेल कॉल, कम-आवृत्ति वाले समाधान (reconciliation), और महत्वपूर्ण ग्राहक अभी भी इस पर निर्भर हो सकते हैं → कंज्यूमर द्वारा एडॉप्शन, दायित्वों और शेष ट्रैफ़िक को सत्यापित करें, फिर रिकवरी का रिहर्सल करें।
• केवल सर्वर-साइड 2xx दरों को देखना → एक क्लाइंट रिस्पॉन्स प्राप्त कर सकता है लेकिन इसे पार्स करने में विफल हो सकता है, पेज छोड़ सकता है, या किसी नए स्टेटस की गलत व्याख्या कर सकता है → पुराने-SDK परिणाम, पेजिनेशन पूर्णता, एंड-टू-एंड परिणाम और सहायता सिग्नल जोड़ें।

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

फॉलो-अप 1: क्या एक ही कंपनी के स्वामित्व वाले तीन आंतरिक कंज्यूमर्स को v2 की आवश्यकता है?

ज़रूरी नहीं। यदि प्रत्येक कॉलर की पहचान की जा सकती है, रिलीज़ का समन्वय किया जा सकता है, और रोलबैक तेज़ है, तो expand–migrate–contract का उपयोग करें: एक कम्पैटिबल फ़ील्ड या एंडपॉइंट जोड़ें, ऐसे कंज्यूमर्स रिलीज़ करें जो दोनों आकारों को पढ़ सकें, प्रोड्यूसर को स्विच करें, फिर मापा गया उपयोग शून्य होने के बाद पुराने अनुबंध को हटा दें। कॉन्ट्रैक्ट टेस्ट और वर्ज़न्ड डिप्लॉयमेंट साक्ष्य अभी भी मायने रखते हैं, लेकिन नियंत्रणीय कंज्यूमर्स को स्थायी पब्लिक v2 की आवश्यकता नहीं होती है। एक गैर-समन्वित ऑफ़लाइन जॉब, पुराना क्लाइंट या बाहरी पार्टनर उस धारणा को अमान्य कर देता है।

फॉलो-अप 2: क्या वेबहुक इवेंट्स को अकाउंट के वर्तमान API वर्ज़न का पालन करना चाहिए?

रीप्ले के दौरान "वर्तमान" वर्ज़न के साथ ऐतिहासिक घटनाओं की पुनर्व्याख्या न करें। एंडपॉइंट बनने पर एक इवेंट API वर्ज़न पिन करें, इसे इवेंट के साथ रिकॉर्ड करें, और पुनः प्रयास और रीप्ले के लिए मूल आकार को बनाए रखें। एक नए वर्ज़न वाले एंडपॉइंट को बनाकर या उस पर स्विच करके और कंज्यूमर को मान्य करके अपग्रेड करें। Stripe का पब्लिक दस्तावेज़ भी वेबहुक इवेंट शेप को एंडपॉइंट निर्माण के समय API वर्ज़न से जोड़ता है। पुराने और नए दोनों इवेंट भेजना डुप्लिकेट साइड इफ़ेक्ट पैदा करता है और केवल एक छोटे माइग्रेशन के रूप में सुरक्षित होता है जब कंज्यूमर्स एक स्थिर इवेंट ID द्वारा डुप्लीकेशन हटाते हैं।

फॉलो-अप 3: क्या एक नई रिस्पॉन्स enum वैल्यू एक ब्रेकिंग चेंज है?

यह प्रकाशित अनुबंध पर निर्भर करता है। GitHub एक enum वैल्यू जोड़ने को एडिटिव के रूप में सूचीबद्ध करता है, जबकि Google का कम्पैटिबिलिटी मार्गदर्शन यह भी चेतावनी देता है कि पुराना कोड नई रिस्पॉन्स enum वैल्यू को सुचारू रूप से संभाल नहीं सकता है। उस तनाव को स्पष्ट रूप से बताएं। यदि अनुबंध एक ओपन सेट को परिभाषित करता है, SDK एक अज्ञात रिप्रेजेंटेशन को एक्सपोज़ करता है, और कंज्यूमर्स को इसे सहन करना चाहिए, तो बदलाव कम्पैटिबल हो सकता है। यदि प्रकार क्लोज्ड है या इकोसिस्टम में एग्जॉस्टिव स्विच शामिल हैं, तो इसे एक ब्रेकिंग जोखिम के रूप में मानें: पहले SDK और अनुबंध में सुधार करें या वैल्यू को एक नए वर्ज़न में रखें। केवल सर्वर-साइड स्कीमा तय नहीं कर सकता।

फॉलो-अप 4: अनबाउंड v1 लिस्ट टाइम आउट हो रही है। क्या होगा यदि माइग्रेशन समय पर पूरा नहीं हो पाता है?

पहले मौजूदा अनुबंध द्वारा अनुमत नियंत्रणों के साथ सेवा को रीस्टोर करें: कोटा, कैशिंग, क्वेरी ऑप्टिमाइज़ेशन और बैकप्रेशर, जबकि सीधे उच्च-मात्रा वाले कंज्यूमर्स को v2 पर ले जाएं। यदि एक आपातकालीन रिस्पॉन्स कैप अपरिहार्य है, तो बताएं कि यह v1 को तोड़ सकता है, घटना और परिवर्तन-अनुमोदन प्रक्रिया का उपयोग करें, प्रभावित दायरे की घोषणा करें, बल्क एक्सपोर्ट या एक अस्थायी कम्पैटिबिलिटी चैनल प्रदान करें, और गायब डेटा जोखिम की निगरानी करें। 200 रिस्पॉन्स के साथ पहले 100 रिकॉर्ड चुपचाप लौटाना उपलब्धता की घटना को एक कठिन-से-पहचाने जाने वाले डेटा एरर में बदल देता है; यह कोई कम्पैटिबल समाधान नहीं है।

फॉलो-अप 5: शटडाउन की तारीख आ गई है, लेकिन 0.2% ट्रैफ़िक अभी भी v1 का उपयोग करता है। आगे क्या?

प्रतिशत को कंज्यूमर्स और व्यावसायिक उद्देश्य में विभाजित करें: एक प्रोब, खराब कॉन्फ़िगरेशन, महीने के अंत का जॉब, या अनुबंधित ग्राहक। बिना किसी व्यावसायिक निर्भरता वाले पहचान योग्य ट्रैफ़िक को हटाएं। महत्वपूर्ण कंज्यूमर्स को अपग्रेड, अपवाद या समर्थन एस्केलेशन की आवश्यकता होती है। प्रकाशित नीति और जोखिम मॉडल के तहत अज्ञात ट्रैफ़िक को संभालें। शेष कॉल, अधिसूचना साक्ष्य, समर्थन दायित्व, रिकवरी योजना और निर्णय मालिक को रिकॉर्ड करें। अकेले एक प्रतिशत न तो यह साबित करता है कि शटडाउन सुरक्षित है और न ही यह कि वर्ज़न हमेशा जीवित रहना चाहिए।