सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
अपनी API कुंजी तीन अलग तरीकों से भेजें (और यह क्यों मायने रखता है)
API से बात करने वाला हर टूल ऑथेंटिकेशन को एक ही तरह नहीं संभालता, इसीलिए API सब कुछ एक ही हेडर नाम से भेजने के लिए मजबूर करने के बजाय एक से ज़्यादा तरीकों से कुंजी स्वीकार करती है।
X-API-Key हेडर
यह सबसे सीधा विकल्प है, एक खास हेडर जिसमें कुंजी के सिवा कुछ नहीं होता।
GET /v1/forward?q=Baker+Street
X-API-Key: mg_live_examplekey123Authorization: Bearer
कुछ HTTP क्लाइंट और API गेटवे पहले से हर बाहर जाने वाले अनुरोध के साथ bearer टोकन जोड़ने के लिए सेट होते हैं, और उसी तरीके का उपयोग करने का मतलब है कि आपको उसके साथ एक दूसरा, API के लिए खास हेडर जोड़ने की ज़रूरत नहीं पड़ती।
GET /v1/forward?q=Baker+Street
Authorization: Bearer mg_live_examplekey123HTTP Basic ऑथेंटिकेशन
पुराने टूल, और दूसरे प्रोवाइडरों के लिए बने कुछ सर्वर-से-सर्वर इंटीग्रेशन, क्रेडेंशियल HTTP Basic auth के रूप में चाहते हैं। कुंजी यूज़रनेम के रूप में जाती है, और पासवर्ड खाली छोड़ा जाता है।
GET /v1/forward?q=Baker+Street
Authorization: Basic bWdfbGl2ZV9leGFtcGxla2V5MTIzOg==बाकी सब के लिए, एक क्वेरी पैरामीटर
जब कोई टूल आपको हेडर पर बिल्कुल भी नियंत्रण नहीं देता, जैसे ब्राउज़र के एड्रेस बार में एक झटपट टेस्ट या ऐसा क्लाइंट जो सिर्फ़ URL आधारित कॉन्फ़िगरेशन सपोर्ट करता है, तो कुंजी सीधे अनुरोध पर क्वेरी पैरामीटर के रूप में भी भेजी जा सकती है।
GET /v1/forward?q=Baker+Street&key=mg_live_examplekey123व्यवहार में यह चुनाव क्यों मायने रखता है
क्वेरी पैरामीटर के रूप में भेजी गई कुंजी, अनुरोध हेडर में भेजी गई कुंजी की तुलना में सर्वर लॉग, ब्राउज़र हिस्ट्री और referrer हेडर में ज़्यादा आसानी से पहुँच जाती है, इसलिए जब भी कॉल करने वाले कोड पर आपका कोई भी नियंत्रण हो, हेडर आधारित तरीका चुनें। चारों तरीके हर एंडपॉइंट और हर कम्पैटिबिलिटी होस्ट पर एक जैसे काम करते हैं, इसलिए बाद में इनके बीच बदलना, मान लीजिए किसी स्क्रिप्ट को ब्राउज़र टेस्ट से एक सही बैकएंड इंटीग्रेशन पर ले जाते समय, इस बात में कुछ नहीं बदलता कि कुंजी पर कोटा या क्रेडिट कैसे गिना जाता है।
कम्पैटिबिलिटी होस्ट पर इसका उपयोग
सभी 17 कम्पैटिबिलिटी होस्ट क्रेडेंशियल उसी शैली में स्वीकार करते हैं जो मूल प्रोवाइडर इस्तेमाल करता था, इसलिए किसी दूसरे प्रोवाइडर के ऑथेंटिकेशन तरीके के लिए लिखी गई स्क्रिप्ट आम तौर पर मिलते-जुलते My Geocode कम्पैटिबिलिटी होस्ट की ओर मोड़ने के बाद भी काम करती रहती है, कुंजी भेजने का तरीका दोबारा लिखे बिना। होस्ट की सूची और हर होस्ट किस क्रेडेंशियल शैली की अपेक्षा करता है, यह जानने के लिए कम्पैटिबिलिटी पेज देखें।
एक गलती जिससे बचना चाहिए
किसी स्क्रिप्ट को क्वेरी पैरामीटर वाली कुंजी से टेस्ट करना और प्रोडक्शन में उसे वैसे ही छोड़ देना एक आसानी से लगने वाली आदत है, क्योंकि पहला अनुरोध चलाने का सबसे तेज़ तरीका अक्सर क्वेरी पैरामीटर ही होता है। स्क्रिप्ट के प्रोडक्शन ट्रैफ़िक के आसपास भी पहुँचने या किसी साझा रिपॉज़िटरी में चेक इन होने से पहले हेडर आधारित तरीके, X-API-Key या Authorization, पर चले जाएँ, क्योंकि URL में दिखने वाली कुंजी के ऐसी जगह पहुँचने की संभावना कहीं ज़्यादा होती है जहाँ आप उसे नहीं चाहते थे, जैसे किसी प्रॉक्सी लॉग में या किसी साझा मशीन की ब्राउज़र हिस्ट्री फ़ाइल में।
लागत में कोई अंतर नहीं
इनमें से कोई भी तरीका अनुरोध के बिल बनने के तरीके को नहीं बदलता। कुंजी पर हर अनुरोध अब भी उसी तरह उसके प्रतिदिन 2,500 मुफ़्त अनुरोधों में गिना जाता है, और उसके बाद प्रीपेड क्रेडिट या Unlimited पैकेज में।
सही ऑथेंटिकेशन तरीका चुनना ज़्यादातर इस बात से जुड़ा है कि कॉल करने वाला टूल पहले से क्या सपोर्ट करता है, न कि परफ़ॉर्मेंस या लागत से। पूरी जानकारी ऑथेंटिकेशन दस्तावेज़ में है।