पदावनति (Deprecations)

Bird तीन अलग-अलग चीज़ों को पदावनत करता है, और वे अलग-अलग तरीके से व्यवहार करती हैं। एक request फ़ील्ड का नाम बदला जाता है, और पुराना नाम नए के साथ काम करता रहता है। एक query parameter को एक बेहतर फ़िल्टर द्वारा प्रतिस्थापित किया जाता है, और यह बिना बदलाव के काम करता रहता है। एक request body शेप को एक नए शेप द्वारा प्रतिस्थापित किया जाता है, और पुराना शेप स्वीकार किया जाता रहता है। हर स्थिति में, इनमें से किसी का उपयोग करने वाला request एक Deprecation रिस्पॉन्स हेडर के साथ वापस आता है जो आपको यह बताता है।

हेडर

एक ऐसे request का रिस्पॉन्स जिसमें पदावनत फ़ील्ड, parameter, या body शेप शामिल था, इसमें यह होता है:

हेडर	मान
Deprecation	पदावनति घोषित होने की तारीख, उदाहरण के लिए @1786579200
Link	<https://bird.com/docs/api/deprecations>; rel="deprecation"

Deprecation का मान रिकॉर्ड करता है कि पुराना नाम कब पदावनत हुआ, RFC 9745 के अनुसार। यह कोई हटाने की तारीख घोषित नहीं करता।

केवल वर्तमान नामों का उपयोग करने वाले request के रिस्पॉन्स में कोई भी हेडर नहीं होता, इसलिए हेडर की मौजूदगी ही संकेत है: अगर आप इसे कभी नहीं देखते, तो आप जो भेज रहे हैं वह पदावनत नहीं है।

कोई हटाने की तारीख नहीं

Bird कोई Sunset हेडर नहीं भेजता क्योंकि अभी कोई हटाने की तारीख उपलब्ध नहीं है। एक प्रतिस्थापित नाम तभी हटाया जाता है जब उसका उपयोग बंद हो जाता है। Bird हटाने से पहले प्रभावित ग्राहकों से संपर्क करता है।

Deprecation हेडर को अपनी गति से माइग्रेट करने का संकेत मानें। यह हटाने की उलटी गिनती शुरू नहीं करता।

नाम बदला गया request फ़ील्ड

एक प्रतिस्थापित फ़ील्ड नाम ठीक वैसे ही व्यवहार करता है जैसा पहले करता था:

यह अभी भी request पर स्वीकार किया जाता है, और अभी भी वही मान लिखता है।
यह अभी भी रिस्पॉन्स पर लौटाया जाता है, उसके बदले आए नाम के साथ।
अगर आप दोनों भेजते हैं तो वर्तमान नाम प्राथमिक होता है, इसलिए आप एक-एक कॉल साइट को माइग्रेट कर सकते हैं बिना इस चिंता के कि पुराना नाम नए को ओवरराइट कर दे।

नाम बदले गए फ़ील्ड नामों को इस संदर्भ से हटा दिया गया है, और आधिकारिक SDK केवल वर्तमान नाम दिखाते हैं। अपना SDK अपग्रेड करने से request अपने आप वर्तमान फ़ील्ड नाम पर चले जाते हैं।

एक पदावनत query parameter

एक query parameter तब पदावनत होता है जब एक बेहतर फ़िल्टर उसकी जगह ले लेता है। यह नाम बदले गए फ़ील्ड से तीन महत्वपूर्ण तरीकों से अलग व्यवहार करता है:

यह हर जगह प्रकाशित रहता है। इसे संदर्भ और SDK से हटाने पर वे कॉलर टूट जाएंगे जो इसे पहले से भेज रहे हैं, इसलिए यह इस संदर्भ पर अपनी पंक्ति, हर SDK पर अपना फ़ील्ड, CLI पर अपना फ़्लैग, और MCP टूल स्कीमा में अपनी एंट्री बनाए रखता है। अपना SDK अपग्रेड करना आपको माइग्रेट नहीं करता।
कोई रिस्पॉन्स पक्ष नहीं है। एक query parameter केवल request पर दिखाई देता है, इसलिए रिस्पॉन्स body में कुछ नहीं बदलता और पढ़ने के लिए कोई नया नाम नहीं है।
प्रतिस्थापन एक parameter नहीं भी हो सकता। कभी-कभी एक फ़िल्टर को एक जोड़ी द्वारा प्रतिस्थापित किया जाता है, इसलिए parameter का अपना विवरण बताता है कि इसके बजाय क्या उपयोग करें, बजाय किसी एक उत्तराधिकारी की ओर इंगित करने के।

चूंकि अपग्रेड करना आपको माइग्रेट नहीं करता, Deprecation हेडर ही एकमात्र संकेत है जो आपको मिलेगा। इस संदर्भ में parameter का विवरण देखें: एक पदावनत parameter Deprecated: से शुरू होता है और अपने प्रतिस्थापन का नाम बताता है।

एक प्रतिस्थापित request body शेप

बैच भेजने वाले endpoint, POST /v1/sms/batches और POST /v1/email/batches, पहले बैच को एक bare top-level JSON array के रूप में लेते थे। अब वे एक object लेते हैं जिसका messages array वही आइटम रखता है, और यही वह शेप है जो यह संदर्भ दस्तावेज़ित करता है। एक request जिसका body अभी भी bare array है, पहले की तरह ही काम करता है, और Deprecation हेडर के साथ वापस आता है। आधिकारिक SDK messages object भेजते हैं, इसलिए अपना SDK अपग्रेड करने से आपके request वर्तमान शेप पर चले जाते हैं।

माइग्रेट करना

अपने रिस्पॉन्स पर Deprecation हेडर पर नज़र रखें।
वह request ढूंढें जिसने यह हेडर उत्पन्न किया, और वर्तमान नाम और request शेप देखने के लिए इस संदर्भ में ऑपरेशन जांचें।
वर्तमान नाम या शेप पर जाएं। एक बार माइग्रेट करने के बाद केवल वर्तमान रूप भेजें।

वर्तमान पदावनतियाँ

ऑपरेशन	पदावनत	इसके बजाय उपयोग करें
WhatsApp: संदेश सूचीबद्ध करें	phone_number query parameter	to या from
SMS और email: संदेशों का एक बैच बनाएं	bare-array request body	messages वाला एक object

कोई फ़ील्ड नाम बदलाव पदावनत नहीं है। किसी संपर्क का फ़ोन नंबर phone_number है और सत्यापन प्राप्तकर्ता का ईमेल पता to के अंदर email है; इनकी कोई भी अन्य स्पेलिंग validation error के रूप में अस्वीकार की जाती है, हर उस ऑपरेशन पर जो इन्हें लेता है।

WhatsApp संदेश सूची पर to और from प्रत्येक संदेश के एक छोर से मैच करते हैं, और प्रत्येक एक फ़ोन नंबर या business-scoped user ID स्वीकार करता है। phone_number किसी भी दिशा में संपर्क से मैच करता था, इसलिए जिस खोज को दिशा की परवाह नहीं है उसे दोनों फ़िल्टर चाहिए, हर एक के लिए एक request।

संबंधित संसाधन