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