इस महीने हमने क्या लॉन्च किया: जियोकोडिंग, IP, समय क्षेत्र और बहुत कुछ
पूरे API में हाल के काम का सार: नए कम्पैटिबिलिटी होस्ट, तेज़ समय क्षेत्र और ऊँचाई लुकअप, डैशबोर्ड की सुविधाएँ, और कोटा की ज़्यादा साफ़ जानकारी।
हर एंडपॉइंट पर एक साफ़ एरर फ़ॉर्मेट
एरर रिस्पॉन्स किसी API का फ़ुटनोट नहीं है, यह उस अनुबंध का हिस्सा है जिस पर हर इंटीग्रेशन उतना ही निर्भर करता है जितना सफल रिस्पॉन्स पर। हमने My Geocode के हर नेटिव एंडपॉइंट पर एरर फ़ॉर्मेट को मानकीकृत कर दिया है, ताकि कोई विफलता एक जैसी दिखे, चाहे वह API के किसी भी हिस्से से आई हो।
चाहे कोई अनुरोध किसी गायब पैरामीटर, अमान्य कुंजी, खत्म हो चुके कोटा या गलत फ़ॉर्मेट वाले निर्देशांक की वजह से विफल हो, रिस्पॉन्स एक ही, अनुमानित संरचना का पालन करता है। इस एकरूपता का मतलब है कि एक एंडपॉइंट के लिए एक बार लिखा गया एरर-हैंडलिंग कोड बाकी हर नेटिव एंडपॉइंट पर भी उसी तरह काम करता है, हर एक के लिए अलग हैंडलिंग लॉजिक की ज़रूरत के बिना।
कोटा से जुड़ी विफलताओं का खास तौर पर ज़िक्र ज़रूरी है, क्योंकि किसी सक्रिय इंटीग्रेशन को सबसे ज़्यादा इन्हीं का सामना करना पड़ता है। जब कोई अनुरोध किसी कुंजी या नेटवर्क के कोटे से आगे चला जाता है, तो रिस्पॉन्स यह साफ़ बताता है, और हर रिस्पॉन्स पर पहले से मौजूद कोटा हेडर, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining और बाकी, आपको ठीक-ठीक बताते हैं कि विफल हुए अनुरोध से पहले कितनी गुंजाइश बची थी। इस मेल का मतलब है कि क्लाइंट सिर्फ़ रिस्पॉन्स से ही कोटा की समस्या को ऑथेंटिकेशन की समस्या या गलत अनुरोध से अलग पहचान सकता है, बिना अंदाज़ा लगाए।
कम्पैटिबिलिटी होस्ट इस मानकीकरण का एक सोचा-समझा अपवाद हैं, और इसकी ठोस वजह है। उनका पूरा उद्देश्य किसी दूसरे प्रोवाइडर के अनुरोध और रिस्पॉन्स की संरचना को ठीक वैसा ही दोहराना है, और इसमें यह भी शामिल है कि एरर कैसे दिखते हैं। Bing Maps REST Services के अनुरूप बना कोई अनुरोध विफल होने पर भी Bing के अपने एरर फ़ॉर्मेट में ही एरर पाता है, क्योंकि उस संरचना से सटीक मेल, चाहे सफलता हो या विफलता, ड्रॉप-इन होस्ट का पूरा मकसद है। वहाँ एरर को मानकीकृत करने से वही कम्पैटिबिलिटी टूट जाएगी जिसके लिए होस्ट बना है।
हमारे नेटिव एंडपॉइंट पर बनी किसी भी चीज़ के लिए, इस साफ़ फ़ॉर्मेट से एरर हैंडलिंग लिखना और बनाए रखना काफ़ी आसान हो जाना चाहिए। एक ही पार्सिंग रूटीन, अपेक्षित फ़ील्ड का एक ही सेट, और /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete और /v1/postcode पर एक जैसा व्यवहार।
एरर फ़ॉर्मेट का पूरा दस्तावेज़, फ़ील्ड के नाम और आम कारणों सहित, /docs/errors/ पर उपलब्ध है। अगर आपके इंटीग्रेशन में अभी अलग-अलग नेटिव एंडपॉइंट के लिए अलग एरर-हैंडलिंग शाखाएँ हैं, तो उन्हें घटाकर एक करने का यह अच्छा मौका है।