कभी एक्सपायर न होने वाली API कुंजियों की समस्या
कई साल पहले जारी की गई कुंजी, जिसे कभी रोटेट नहीं किया गया और जो आज भी मान्य है, कोई सुविधा नहीं है। यह एक जोखिम है जिसे सालों से किसी ने वास्तव में देखा तक नहीं।
बुनियादी ऑथेंटिकेशन तरीकों के लिए अतिरिक्त शुल्क लेने के ख़िलाफ़ तर्क
ऑथेंटिकेशन किसी API के उपयोग का एक साधारण हिस्सा है, और ठीक इसी तरह का साधारण विवरण ज़रूरत से ज़्यादा बार किसी मूल्य स्तर के पीछे बंद कर दिया जाता है। कुछ प्रदाता कुछ ऑथेंटिकेशन तरीकों, जैसे HTTP Basic auth या Bearer token पैटर्न, को ऊँचे भुगतान वाले स्तरों के लिए सुरक्षित रखते हैं, जबकि निचला स्तर केवल एक खास हेडर फ़ॉर्मेट को सपोर्ट करता है। एक ऑथेंटिकेशन शैली और दूसरी को वैलिडेट करने की तकनीकी लागत का अंतर लगभग शून्य है। फ़र्क बस इतना है कि किसी ग्राहक के मौजूदा कोड के लिए कौन-सा तरीका कितना सुविधाजनक है, और इसका इस बात से कोई लेना-देना नहीं कि उन्हें API इस्तेमाल करने के लिए कितना भुगतान करना चाहिए।
हम कुंजी को X-API-Key हेडर, Authorization Bearer हेडर, यूज़रनेम के रूप में कुंजी के साथ HTTP Basic auth, या क्वेरी पैरामीटर के रूप में, हर होस्ट पर स्वीकार करते हैं, और इनमें से किसी के लिए कोई अतिरिक्त शुल्क नहीं है। जो भी पैटर्न आपके मौजूदा कोड में पहले से फ़िट बैठता है, आपकी टीम अन्य API के लिए जो भी लाइब्रेरी या आंतरिक परंपरा पहले से इस्तेमाल करती है, वह बहुत संभव है कि पहले से सपोर्ट हो, और सिर्फ़ किसी ऐसे फ़ॉर्मेट से मेल खाने के लिए कुछ भी दोबारा ढाँचा बनाने की ज़रूरत नहीं जिसे हम पसंद करते हों।
ऑथेंटिकेशन तरीकों को स्तर के हिसाब से बंद करने के पीछे का तर्क असल में लागत के बारे में नहीं है। यह स्तरों को अलग दिखाने के लिए स्तरों को अलग करने के बारे में है: ऊँचा भुगतान करने वाले ग्राहक के लिए सुरक्षित रखने लायक फ़ीचर ढूँढना, उन फ़ीचर को भी जिन्हें देने में कोई अतिरिक्त लागत नहीं, सिर्फ़ इसलिए कि ऊँचे स्तर के पीछे ज़्यादा फ़ीचर बंद होने से तुलना तालिका में ऊँचा स्तर ज़्यादा मूल्यवान दिखता है। ऑथेंटिकेशन तरीके इसके लिए आसान निशाना हैं, क्योंकि कई तरीकों को सपोर्ट करना प्रदाता के लिए सच में कम मेहनत का काम है और ग्राहक के लिए सच में सुविधाजनक है, जिससे इसे बंद करना पूरी तरह कमाई का फ़ैसला बन जाता है, न कि किसी असली लागत अंतर पर आधारित फ़ैसला।
हमें लगता है कि इस तरह की पाबंदी डेवलपरों को चुपचाप एक ऐसे फ़ैसले के लिए सज़ा देती है जिसका असली डेटा से मिलने वाले मूल्य से कोई लेना-देना नहीं। जिस टीम के मौजूदा टूल डिफ़ॉल्ट रूप से Bearer token इस्तेमाल करते हैं, उसे उस टीम से ज़्यादा भुगतान नहीं करना चाहिए जिसके टूल डिफ़ॉल्ट रूप से कस्टम हेडर इस्तेमाल करते हैं, जब दोनों टीमें बिल्कुल एक जैसा लुकअप माँग रही हैं और बिल्कुल एक जैसा जवाब पा रही हैं। उत्पाद का मूल्य उसका जवाब है। ऑथेंटिकेशन तरीका प्लंबिंग है, और प्लंबिंग पर इस आधार पर कीमत नहीं लगनी चाहिए कि कौन-सा पाइप आपकी मौजूदा दीवार में फ़िट बैठता है।
यहाँ एक व्यापक सिद्धांत है जो सिर्फ़ ऑथेंटिकेशन से आगे भी लागू होता है: जिन फ़ीचर को देने में प्रदाता को कोई अतिरिक्त लागत नहीं आती, उन्हें सिर्फ़ इसलिए कृत्रिम स्तर-सीमाएँ नहीं बनना चाहिए क्योंकि ऐसा किया जा सकता है। अनुरोधों की मात्रा जैसे असली लागत अंतरों पर बनी स्तर संरचना का बचाव किया जा सकता है। ऊँचा भुगतान करने वालों के लिए सुरक्षित रखी गई कम लागत वाली सुविधाओं से भरी स्तर संरचना मुख्य रूप से इसलिए होती है कि मूल्य निर्धारण पेज, असली उत्पाद की तुलना में, ज़्यादा अलग-अलग दिखे।