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