Google Maps Platform से माइग्रेट करना: क्या बदलता है, क्या वैसा ही रहता है

Google Maps Platform अक्सर वह पहला जियोकोडिंग API होता है जिसे कोई टीम जोड़ती है, ज़्यादातर इसलिए क्योंकि यह सबसे बड़ा नाम है। इसका ऑथेंटिकेशन मॉडल अब तक ज़्यादातर डेवलपर्स के लिए जाना-पहचाना है: Google Cloud प्रोजेक्ट के अंदर एक बिलिंग खाते से जुड़ी API कुंजी, जो हर अनुरोध पर क्वेरी पैरामीटर के रूप में भेजी जाती है। इसके जियोकोडिंग रिस्पॉन्स एक JSON ऑब्जेक्ट के रूप में आते हैं जिसमें एक results ऐरे, एक status फ़ील्ड, एक formatted_address स्ट्रिंग और अक्षांश व देशांतर वाला एक नेस्टेड geometry.location ऑब्जेक्ट होता है।

बदलाव को लेकर टीमों को आम तौर पर जो बात चिंतित करती है, वह है ठीक इसी ढाँचे के इर्द-गिर्द बना पार्सिंग कोड। पते के घटक, व्यूपोर्ट की सीमाएँ, place ID, यह सब कोडबेस में जगह-जगह बिखरे फ़ंक्शन पढ़ते हैं, और उन फ़ंक्शन को दोबारा लिखना ऐसा काम है जिसे कोई भी शेड्यूल नहीं करना चाहता। कम्पैटिबिलिटी होस्ट ठीक इसी समस्या से बचने के लिए बना है।

My Geocode एक Google Maps कम्पैटिबिलिटी होस्ट चलाता है जो Google के अपने जियोकोडिंग अनुरोध और रिस्पॉन्स फ़ॉर्मेट को फ़ील्ड-दर-फ़ील्ड दोहराता है। रिस्पॉन्स में हमारा सिर्फ़ कॉपीराइट, शर्तों और गोपनीयता का टेक्स्ट है; बाकी सब कुछ, फ़ील्ड के नाम और नेस्टिंग सहित, वही है जिसकी आपका कोड पहले से उम्मीद करता है। व्यवहार में, माइग्रेट करने का मतलब होस्ट का नाम और कुंजी बदलना है, पार्सर को छूना नहीं। विवरण /compatibility/google-maps/ पर है।

क्या वैसा ही रहता है:

• वह JSON ढाँचा जिसे आपका कोड पहले से पार्स करता है
• कुंजी भेजने की क्वेरी पैरामीटर शैली, अगर आपका क्लाइंट यही उपयोग करता है
• अनुरोध का सामान्य पैटर्न (पता अंदर, संरचित लोकेशन डेटा बाहर)

क्या बदलता है:

• वह होस्ट जिस पर आप अनुरोध भेजते हैं
• खुद कुंजी, जो Google के बजाय हम जारी करते हैं
• बिलिंग खाते की ज़रूरत, जिसकी जगह एक सरल क्रेडिट या सब्सक्रिप्शन मॉडल ले लेता है

चूँकि कुंजी X-API-Key हेडर, Authorization: Bearer हेडर, HTTP Basic auth या क्वेरी पैरामीटर के रूप में भेजी जा सकती है, जो क्लाइंट लाइब्रेरी पहले से अपने खास तरीके से ऑथेंटिकेट करती है वह आम तौर पर बिना बदलाव के काम करती रहती है। यह लचीलापन जितना सुनने में लगता है उससे ज़्यादा मायने रखता है, क्योंकि व्यवहार में माइग्रेशन की बहुत सी परेशानी उन लाइब्रेरी से आती है जो क्रेडेंशियल भेजने का एक ही खास तरीका मानकर चलती हैं।

मूल्य के मामले में मॉडल सरल है: किसी भी पते से बिना कुंजी के प्रतिदिन 2,500 अनुरोध मुफ़्त हैं, और हर कुंजी को भी प्रति नेटवर्क गिने जाने वाले प्रतिदिन 2,500 मुफ़्त अनुरोध मिलते हैं। उसके बाद €0.0001 प्रति अनुरोध की दर से प्रीपेड क्रेडिट है, या €50 प्रति माह में Unlimited पैकेज, और हर एंडपॉइंट की कीमत एक जैसी है, हर कम्पैटिबिलिटी होस्ट सहित। आप किस प्रोडक्ट को कॉल करते हैं, इसके आधार पर मोलभाव करने के लिए कोई अलग टियर नहीं हैं।

वैकल्पिक अतिरिक्त फ़ील्ड (ज़मीन की ऊँचाई, IP खतरे के संकेत और नेटवर्क विवरण) किसी भी कम्पैटिबिलिटी होस्ट पर mg_extras=1 या X-MG-Extras हेडर जोड़कर उपलब्ध हैं, उस ढाँचे को तोड़े बिना जिस पर आपका बाकी कोड निर्भर है। इससे आपको बाद में दूसरे माइग्रेशन के बिना ज़्यादा समृद्ध डेटा का रास्ता मिलता है।

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

• X
• LinkedIn
• Facebook
• Reddit
• Hacker News
• Telegram
• WhatsApp
• Mastodon
• ईमेल