डेप्रिकेशन

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

हेडर

जिस अनुरोध में डेप्रिकेटेड फ़ील्ड, पैरामीटर या बॉडी ढांचा हो, उसकी प्रतिक्रिया में ये शामिल होते हैं:

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

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

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

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

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

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

नाम बदला गया अनुरोध फ़ील्ड

पुराना फ़ील्ड नाम ठीक पहले की तरह काम करता है:

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

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

अप्रचलित क्वेरी पैरामीटर

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

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

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

बदला गया अनुरोध बॉडी स्वरूप

बैच भेजने वाले एंडपॉइंट, POST /v1/sms/batches और POST /v1/email/batches, पहले बैच को सीधे शीर्ष-स्तरीय JSON ऐरे के रूप में लेते थे। अब वे एक ऑब्जेक्ट लेते हैं, जिसके messages ऐरे में वही आइटम होते हैं। यही स्वरूप यह रेफ़रेंस बताता है। जिस अनुरोध का बॉडी अब भी सीधा ऐरे है, वह पहले की तरह ही काम करता है और उसकी प्रतिक्रिया में Deprecation हेडर आता है। आधिकारिक SDKs messages ऑब्जेक्ट भेजते हैं, इसलिए अपना SDK अपग्रेड करने पर आपके अनुरोध मौजूदा स्वरूप में चले जाते हैं।

माइग्रेशन

अपनी प्रतिक्रियाओं में Deprecation हेडर पर नज़र रखें।
वह अनुरोध खोजें जिससे यह हेडर आया। फिर मौजूदा नाम और अनुरोध स्वरूप जानने के लिए इस रेफ़रेंस में उस ऑपरेशन को देखें।
मौजूदा नाम या स्वरूप अपनाएँ। ऐसा करने के बाद केवल मौजूदा रूप ही भेजें।

मौजूदा डेप्रिकेशन

ऑपरेशन	डिप्रिकेटेड	इसके बजाय उपयोग करें
WhatsApp: संदेशों की सूची	`phone_number` क्वेरी पैरामीटर	`to` या `from`
SMS और ईमेल: संदेशों का बैच बनाना	केवल ऐरे वाली अनुरोध बॉडी	`messages` वाला ऑब्जेक्ट

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

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

इस विषय के लिए दस्तावेज़, गाइड और उदाहरणों के साथ आगे बढ़ें।

इम्प्लीमेंटेशन ब्रीफ़ पाएँ

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