ब्रेकिंग बदलावों की नीति

परिचय

तेज़ डेवलपमेंट और स्थिरता बनाए रखने के बीच संतुलन के लिए, ElevenLabs के पास API के दायरे में ब्रेकिंग चेंज माने जाने वाले बदलावों के लिए खास दिशानिर्देश हैं। यहाँ बताया गया है कि हम किन बदलावों को ब्रेकिंग चेंज मानते हैं और किन्हें नहीं।

रिस्पॉन्स और स्कीमा में बदलाव

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

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

पैरामीटर में बदलाव

API पैरामीटर में बदलाव एक सख्त कंपैटिबिलिटी मॉडल का पालन करते हैं। मौजूदा एंडपॉइंट्स में ज़रूरी पैरामीटर जोड़ना हमेशा ब्रेकिंग चेंज होता है, क्योंकि मौजूदा क्लाइंट कॉल्स वैलिडेशन में विफल हो जाएँगी। हालांकि, वैकल्पिक पैरामीटर जोड़ना (जिनके डिफ़ॉल्ट मान हैं या जिन्हें स्पष्ट रूप से वैकल्पिक बताया गया है) ब्रेकिंग नहीं है, क्योंकि मौजूदा क्लाइंट कॉल्स बिना बदलाव के जारी रह सकती हैं। इसी तरह, पैरामीटर टाइप या फ़ॉर्मैट में कोई भी बदलाव, या पहले वैकल्पिक रहे पैरामीटर को ज़रूरी बनाना ब्रेकिंग चेंज माना जाता है, क्योंकि इससे क्लाइंट्स के अपेक्षित कॉन्ट्रैक्ट में बदलाव आता है।

एंडपॉइंट और पाथ में बदलाव

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