Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
ipstack बनाम ip-api.com बनाम ipinfo.io: डेटा की संरचना की तुलना
IP जियोलोकेशन प्रदाता ज़्यादातर एक जैसी श्रेणियों के मूल डेटा पर निर्भर करते हैं (देश, क्षेत्र, शहर, निर्देशांक और नेटवर्क का स्वामित्व), लेकिन वे इसे स्पष्ट रूप से अलग-अलग ढाँचों में पेश करते हैं, और जब आप उनका मूल्यांकन करते हैं या उनके बीच बदलाव करते हैं, तो यही ढाँचे असल इंटीग्रेशन के काम का आश्चर्यजनक रूप से बड़ा हिस्सा तय करते हैं।
ip-api.com सपाट (flat) ढाँचा पसंद करता है। country, regionName, city, lat, lon, isp और query जैसे फ़ील्ड बिना किसी नेस्टिंग के सीधे रिस्पॉन्स के शीर्ष स्तर पर होते हैं, जिससे इसे पढ़ना तेज़ होता है और किसी सपाट डेटाबेस पंक्ति या एक लॉग लाइन पर मैप करना आसान होता है।
ipinfo.io आम तौर पर साथ आने वाले दो मानों को एक ही स्ट्रिंग में समेट देता है: एक loc फ़ील्ड जिसमें अक्षांश और देशांतर एक साथ कॉमा से अलग की गई स्ट्रिंग के रूप में होते हैं, और एक org फ़ील्ड जो ऑटोनॉमस सिस्टम नंबर और संगठन के नाम को एक स्ट्रिंग में जोड़ता है, कुछ इस तरह जैसे AS नंबर के बाद कंपनी का नाम। यह लॉगिंग और जल्दी दिखाने के लिए कुशल है, लेकिन किसी भी मान को सही संख्या के रूप में उपयोग करने या प्रोग्राम से तुलना करने से पहले उसे विभाजित (split) करना पड़ता है।
ipstack उल्टी दिशा में जाकर ज़्यादा ढाँचा देता है। यह type, continent_code, latitude और longitude जैसे शीर्ष-स्तरीय फ़ील्ड अलग-अलग मानों के रूप में लौटाता है, और नेटवर्क व ISP के विवरण को किसी सपाट स्ट्रिंग के बजाय नेस्टेड connection ऑब्जेक्ट में समूहित करता है, जो उन एप्लिकेशन के लिए उपयुक्त है जो उस विवरण को डेटा के अपने अलग हिस्से के रूप में रखना चाहते हैं।
इन तीनों में से कोई भी ढाँचा वस्तुनिष्ठ रूप से बेहतर नहीं है; ये इस बारे में अलग-अलग मान्यताओं को दर्शाते हैं कि कॉल करने वाला डेटा का उपयोग कैसे करेगा। सपाट ढाँचे पर तुरंत पार्सिंग कोड लिखना तेज़ होता है। संक्षिप्त संयुक्त-स्ट्रिंग ढाँचा उन लॉगिंग पाइपलाइन के लिए कुशल है जो हर अनुरोध के लिए एक पंक्ति संग्रहीत करती हैं। नेस्टेड ढाँचा ज़्यादा विस्तृत आंतरिक डेटा मॉडल बनाने वाले एप्लिकेशन के लिए संबंधित फ़ील्ड को समूहित रखता है।
My Geocode इन तीनों ढाँचों के लिए हूबहू कम्पैटिबिलिटी होस्ट चलाता है: ip-api के सपाट फ़ील्ड /compatibility/ip-api/ पर, ipinfo की संक्षिप्त loc और org स्ट्रिंग /compatibility/ipinfo/ पर, और ipstack का नेस्टेड connection ऑब्जेक्ट /compatibility/ipstack/ पर। इसका मतलब है कि ऐसी तुलना का अंत सबके लिए चुने गए किसी एक विजेता पर होना ज़रूरी नहीं है; कोई टीम वही ढाँचा चला सकती है जिसकी उसका मौजूदा कोड पहले से उम्मीद करता है, या मूल्यांकन के दौरान एक ही लुकअप डेटा पर एक से ज़्यादा ढाँचों को परख भी सकती है, क्योंकि तीनों होस्ट एक ही प्लेटफ़ॉर्म पर हैं, एक जैसे ऑथेंटिकेशन विकल्पों और एक जैसे मूल्य के साथ।
चूँकि यहाँ IP लुकअप शुरू से अंत तक पूरी तरह काम करते हैं, सिर्फ़ ढाँचे के स्तर पर नहीं, इस तुलना को सीधे परखा जा सकता है: एक छोटी स्क्रिप्ट को एक ही टेस्ट IP पतों के साथ तीनों कम्पैटिबिलिटी होस्ट पर चलाएँ और उस असल आउटपुट ढाँचे की तुलना करें जो आपके अपने पार्सिंग कोड को मिलेगा। इनमें से किसी के लिए भी ऑथेंटिकेशन में X-API-Key हेडर, Authorization: Bearer, HTTP Basic auth या क्वेरी पैरामीटर स्वीकार किए जाते हैं, और तीनों में से किसी पर भी बिना कुंजी के प्रतिदिन 2,500 अनुरोध मुफ़्त हैं, जिससे किसी एक ढाँचे को चुनने से पहले उनकी साथ-साथ ढाँचागत तुलना कम लागत का काम बन जाती है।