कभी एक्सपायर न होने वाली API कुंजियों की समस्या
कई साल पहले जारी की गई कुंजी, जिसे कभी रोटेट नहीं किया गया और जो आज भी मान्य है, कोई सुविधा नहीं है। यह एक जोखिम है जिसे सालों से किसी ने वास्तव में देखा तक नहीं।
उबाऊ, स्थिर API वर्ज़निंग के पक्ष में तर्क
जब कोई प्रदाता किसी बड़े नए API वर्ज़न की घोषणा करता है, तो वह आमतौर पर मौजूदा इंटीग्रेशन वाले हर ग्राहक के लिए एक ऐसे प्रोजेक्ट की घोषणा कर रहा होता है जो उन्होंने माँगा ही नहीं। अच्छी तरह बताया गया ब्रेकिंग बदलाव भी यही मतलब रखता है कि किसी को माइग्रेशन गाइड पढ़ने, अनुरोध या रिस्पॉन्स की हैंडलिंग अपडेट करने, उसे परखने और डिप्लॉय करने के लिए समय निकालना होगा, और यह समयसीमा प्रदाता के रोडमैप से तय होती है, न कि उस ग्राहक के अपने उत्पाद में हो रही किसी बात से।
हमें लगता है कि API स्थिरता को अपने आप में एक डिज़ाइन लक्ष्य माना जाना चाहिए, गति की कमी नहीं। एक बार प्रकाशित होने के बाद रिस्पॉन्स ढाँचे का मतलब वही बना रहना चाहिए जो तब था जब किसी डेवलपर ने पहली बार उस पर निर्माण किया। नए फ़ील्ड वैकल्पिक जोड़ के रूप में जोड़े जा सकते हैं, जैसे ऊँचाई, IP खतरा और नेटवर्क विवरण मानक रिस्पॉन्स पर परत के रूप में जोड़े गए वैकल्पिक अतिरिक्त हैं, न कि उनका ज़बरदस्ती पुनर्गठन। जो चुपचाप नहीं होना चाहिए वह है किसी मौजूदा फ़ील्ड का मतलब बदलना, किसी स्टेटस कोड का नया उपयोग, या उसी वर्ज़न नंबर के तहत किसी ढाँचे का पुनर्गठन।
इस उद्योग में ब्रेकिंग बदलाव इतनी बार होने का एक कारण यह है कि वे प्रदाता के लिए सस्ते और ग्राहक के लिए महँगे होते हैं, और दोनों पक्ष इस असंतुलन पर सीधे शायद ही कभी बातचीत करते हैं। एक साफ़ आंतरिक मॉडल जारी करना प्रदाता की अपनी टीम के लिए एक जायज़ इंजीनियरिंग जीत है। यह बोझ उसी पल बन जाता है जब यह हर डाउनस्ट्रीम इंटीग्रेशन को जवाब में बदलने पर मजबूर करता है, उस समय-सारणी पर जिसे प्रदाता नियंत्रित करता है और ग्राहक नहीं।
इसका मतलब यह नहीं कि API को कभी बदलना नहीं चाहिए। इसका मतलब है कि जहाँ तक संभव हो बदलाव जोड़ने वाले होने चाहिए, और जहाँ असली ब्रेकिंग बदलाव टाला न जा सके, वह इतना दुर्लभ होना चाहिए कि ग्राहक भरोसा कर सके कि जिस ढाँचे पर उसने निर्माण किया वह महीनों या सालों बाद भी काम करेगा, न कि ऐसा कुछ जिससे बचाव के लिए उसे किसी बदलाव सूची पर नज़र रखनी पड़े। स्थिरता ठहराव के समान नहीं है। यह एक वादा है कि आज के इंटीग्रेशन कार्य पर कोई ऐसी समाप्ति तिथि नहीं लगी है जिसके बारे में आपको किसी ने बताया ही नहीं।
ग्राहकों की सद्भावना के अलावा, इस रुख पर टिके रहने का हमारा एक स्वार्थी कारण भी है। हमारा हर कम्पैटिबिलिटी होस्ट समय के साथ किसी दूसरे प्रदाता के ढाँचे से सटीक मेल खाने पर निर्भर है, जो तभी काम करता है जब ढाँचे, एक बार मेल खा जाने के बाद, स्थिर लक्ष्य के रूप में भरोसे लायक हों। जो कंपनी अपने ही API को फेंकने लायक मानती है, जब भी सुविधाजनक हो दोबारा डिज़ाइन करने लायक, उसकी कम्पैटिबिलिटी गारंटी भी असल में गारंटी नहीं होती। स्थिरता एक ऐसी आदत होनी चाहिए जो हर जगह लागू हो, वरना वह असल में कहीं भी लागू नहीं होती।
यहाँ उबाऊ होना आलोचना नहीं है। API का ऐसा वर्ज़न जो सालों बाद भी ठीक वैसे ही काम करता है जैसे आपके पहली बार इंटीग्रेट करते समय करता था, इस बात का सबूत नहीं कि कुछ सुधरा नहीं। यह इस बात का सबूत है कि सुधार ऐसे तरीकों से हुए जिन पर आपको ध्यान देने की ज़रूरत नहीं पड़ी, और अच्छे वर्ज़निंग अनुशासन का पूरा मकसद यही है।