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