Product Manager इंटरव्यू: क्या किसी SaaS को Field-Level API Deprecation Manifest सार्वजनिक करना चाहिए?

प्रॉम्प्ट और स्कोप

आपके SaaS के कई B2B API ग्राहक हैं। टीम जून 2026 के IETF Internet-Draft “A Deprecation Manifest for Field-Level Lifecycle Signalling in HTTP APIs” को अपनाना चाहती है और व्यक्तिगत रिक्वेस्ट या रिस्पॉन्स मेंबर्स के लिए डेप्रिकेशन तिथियों, सनसेट तिथियों और रिप्लेसमेंट्स का विवरण देने के लिए application/deprecations+json को सार्वजनिक करना चाहती है। तय करें कि क्या इसे एक प्रोडक्ट क्षमता बनाना चाहिए और इसके स्कोप, कस्टमर वैल्यू, कम्पैटिबिलिटी, रोलआउट और सफलता मेट्रिक्स की व्याख्या करें। यह ड्राफ़्ट अभी भी काम प्रगति पर है (work in progress), कोई अंतिम RFC नहीं है।

इंटरव्यूअर क्या जांच रहा है

• एक प्रोटोकॉल क्षमता को ग्राहक की समस्या, माइग्रेशन वर्कफ़्लो और व्यावसायिक मूल्य में बदलना।
• रिसोर्स-लेवल रिस्पॉन्स हेडर्स (RFC 9745, RFC 8594) को फ़ील्ड-लेवल मैनिफ़ेस्ट से अलग पहचानना।
• जब तक कोई मानक अधूरा हो, तब तक कमिटमेंट्स, कम्पैटिबिलिटी और गवर्नेंस को नियंत्रित करना।
• अपनाने (adoption), माइग्रेशन पूरा होने और फ़ाल्स पॉज़िटिव्स के लिए अवलोकन योग्य मेट्रिक्स चुनना।

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

1. क्या ग्राहक मुख्य रूप से SDKs, OpenAPI जनरेटर्स या सीधे JSON पार्सिंग का उपयोग करते हैं?
2. क्या आपके पास पहले से ही डेप्रिकेशन नोटिस, वर्ज़न नीति और संपर्क-सूचना तंत्र मौजूद हैं?
3. क्या डेप्रिकेट किए गए मेंबर्स केवल रिस्पॉन्स फ़ील्ड्स हैं, या रिक्वेस्ट फ़ील्ड्स, नेस्टेड ऐरे और पॉलीमॉर्फ़िक शेप्स भी हैं?
4. क्या लक्ष्य मानवीय माइग्रेशन में सहायता करना है या CI/CD और SDKs को स्वचालित रूप से जोखिम को ब्लॉक करने देना है?
5. किन ग्राहकों, क्षेत्रों या अनुपालन मामलों के लिए पुराने मेंबर का उपलब्ध रहना आवश्यक है, और कितने समय के लिए?

30-सेकंड उत्तर फ़्रेमवर्क

समस्या से शुरुआत करें: ग्राहकों को मेंबर-लेवल परिवर्तनों को खोजने में कठिनाई होती है, जबकि रिसोर्स-लेवल Deprecation/Sunset हेडर्स प्रत्येक मेंबर की पहचान नहीं कर सकते। मेरी सिफ़ारिश ड्राफ़्ट को एक स्थिर मानक के रूप में प्रस्तुत किए बिना, एक सीमित, वैकल्पिक फ़ील्ड-लेवल लाइफ़साइकिल सिग्नल पायलट शुरू करने की है। रिस्पॉन्स मेंबर्स, एक मैनिफ़ेस्ट, डॉक्यूमेंटेशन लिंक्स और रिप्लेसमेंट फ़ील्ड्स से शुरुआत करें; OpenAPI, घोषणाओं और रिसोर्स-लेवल हेडर्स को बनाए रखें। इसे आगे बढ़ाना है या नहीं, यह तय करने के लिए डिस्कवरी रेट, माइग्रेशन समय, फ़ाल्स-पॉज़िटिव रेट और रोलबैक रेट का उपयोग करें।

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

1. ग्राहक की समस्या और सीमा को परिभाषित करें

एक डेप्रिकेट किया गया मेंबर अक्सर कुछ समय के लिए रिस्पॉन्स में बना रहता है। ग्राहकों को यह जानने की आवश्यकता होती है कि कौन सा मेंबर प्रभावित है, डेप्रिकेशन कब शुरू होता है, इसे कब हटाए जाने की उम्मीद है और इसका विकल्प क्या है। मैनिफ़ेस्ट डिस्कवरी और ऑर्केस्ट्रेशन का समाधान करता है; यह वर्तमान व्यवहार को नहीं बदलता है और वर्ज़न नीति, कॉन्ट्रैक्ट टेस्ट या मानवीय संचार की जगह नहीं ले सकता।

2. मौजूदा क्षमताओं के साथ संबंध स्पष्ट करें

रिसोर्स-लेवल हेडर्स डिफ़ॉल्ट चैनल बने रहेंगे। एक फ़ील्ड-लेवल मैनिफ़ेस्ट को Link के साथ खोजा जा सकता है:

Link: </.well-known/deprecations>; rel="deprecation"; type="application/deprecations+json"

उदाहरण मैनिफ़ेस्ट:

{
  "deprecations": [
    {
      "target": "response",
      "selector": "$.customer.legacy_name",
      "selectorType": "jsonpath",
      "deprecation": "2026-09-01",
      "sunset": "2027-03-01",
      "replacement": "$.customer.display_name",
      "info": "https://docs.example.com/migrations/customer-name"
    }
  ]
}

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

3. एक मिनिमम वायेबल प्रोडक्ट (MVP) चुनें

JSON रिस्पॉन्स मेंबर्स, एक API वर्ज़न और स्पष्ट तिथियों के साथ शुरुआत करें। हर JSONPath डायलेक्ट, रिक्वेस्ट-बॉडी वेरिएंट, GraphQL शेप, बाइनरी प्रोटोकॉल या स्वचालित क्लाइंट रीराइटिंग का वादा न करें। मैनिफ़ेस्ट को केवल पढ़ने योग्य (read-only) और कैशे करने योग्य रखें, जिसमें सोर्स-डॉक्यूमेंट लिंक और मानवीय पुष्टि का मार्ग शामिल हो।

4. रोलआउट और माइग्रेशन डिज़ाइन करें

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

5. गवर्नेंस, जोखिम नियंत्रण और मेट्रिक्स निर्धारित करें

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

6. चरणबद्ध निर्णय लें

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

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

मैं इसे बनाऊंगा, लेकिन इसे फ़ील्ड-लेवल लाइफ़साइकिल-सिग्नल पायलट के रूप में रखूंगा, न कि एक अंतिम मानक के रूप में। ग्राहक आज रिसोर्स-लेवल Deprecation और Sunset सिग्नल्स प्राप्त कर सकते हैं, फिर भी वे किसी विशेष रिस्पॉन्स मेंबर की पहचान नहीं करते हैं। एक मैनिफ़ेस्ट ऑटोमेशन को मेंबर, तिथियां, रिप्लेसमेंट और माइग्रेशन लिंक प्रदान कर सकता है।

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

यदि पायलट पहले डिस्कवरी और कम सपोर्ट लागत दिखाता है, तो रिक्वेस्ट मेंबर्स और अधिक जटिल शेप्स तक विस्तार करें। यदि ग्राहक पार्सिंग के बजाय डॉक्यूमेंटेशन पर भरोसा करते हैं, तो निवेश को SDKs, CI चेक और नोटिफिकेशन ऑर्केस्ट्रेशन की ओर मोड़ें। सफलता का अर्थ अप्रत्याशित बाधाओं को कम करना और तेज़ माइग्रेशन है, न कि केवल एक प्रोटोकॉल का नाम जोड़ना।

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

• किसी Internet-Draft को स्वीकृत RFC कहना या हर जगह तत्काल समर्थन का वादा करना।
• ओनरशिप, तिथि नीति, नोटिफिकेशन और रोलबैक के बिना केवल JSON सिंटैक्स पर चर्चा करना।
• यह मान लेना कि एक रिस्पॉन्स हेडर मनमाने नेस्टेड मेंबर्स को स्वचालित रूप से ढूंढ सकता है।
• बिना किसी पायलट, मेट्रिक्स और स्टॉप कंडीशन्स के केवल हां/ना का निर्णय देना।
• रिक्वेस्ट मेंबर्स, ऐरे इंडेक्स और पॉलीमॉर्फ़िक शेप्स से उत्पन्न अस्पष्टता को नज़रअंदाज़ करना।

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

क्या होगा यदि ग्राहक मैनिफ़ेस्ट को पार्स नहीं करते हैं?

इसे मशीन द्वारा पढ़े जाने योग्य पूरक के रूप में रखें और OpenAPI, माइग्रेशन दस्तावेज़, SDK चेंजलॉग, वेबहुक या ईमेल नोटिस जारी रखें। इसे ज़बरदस्ती अपनाने के बजाय वास्तविक उपयोग को मापने के लिए डिस्कवरी रेट का उपयोग करें।

आप ड्राफ़्ट परिवर्तनों को कैसे संभालते हैं?

मैनिफ़ेस्ट जनरेटर को ग्राहक API से अलग करें, फ़ॉर्मेट वर्ज़न रिकॉर्ड करें, मैनिफ़ेस्ट को डिसेबल करने या दस्तावेज़ों और रिसोर्स-लेवल हेडर्स पर वापस जाने (fallback) की अनुमति दें, और कम्पैटिबिलिटी नोट्स में ड्राफ़्ट स्थिति को लेबल करें।

आप रिक्वेस्ट मेंबर्स का समर्थन कब करेंगे?

केवल तब जब रिस्पॉन्स-मेंबर पायलट स्थिर सिलेक्टर्स, तिथियां और माइग्रेशन वर्कफ़्लो प्रदर्शित करें, और रिक्वेस्ट मेंबर्स के पास स्पष्ट वैलिडेशन और रोलबैक सिमेंटिक्स हों। अन्यथा एक फ़ाल्स पॉज़िटिव एक विफल राइट (failed write) में बदल सकता है।

आप प्रोडक्ट वैल्यू कैसे साबित करेंगे?

माइग्रेशन पूरा होने के समय, डेप्रिकेटेड-मेंबर कॉल शेयर, सपोर्ट टिकट्स और रोलबैक रेट पर पायलट और कंट्रोल ग्रुप्स की तुलना करें। पार्सर कवरेज और फ़ाल्स पॉज़िटिव्स की भी जांच करें; केवल डॉक्यूमेंटेशन पेज व्यूज़ माइग्रेशन की सफलता को साबित नहीं करते हैं।