Перенос автоматизации Zapier или Make на новый хост геокодирования
No-code автоматизации с шагом геокодирования требуют иного подхода к миграции, чем собственный код. Вот как провести такой переход.
ipstack, ip-api.com и ipinfo.io: сравнение структуры данных
Поставщики IP-геолокации в основном опираются на схожие категории исходных данных (страна, регион, город, координаты и владелец сети), но упаковывают их в заметно разные структуры, и именно эти структуры определяют удивительно большую часть реальной работы по интеграции, когда вы оцениваете поставщиков или переходите с одного на другой.
ip-api.com предпочитает плоскую структуру. Поля country, regionName, city, lat, lon, isp и query находятся прямо на верхнем уровне ответа без вложенности, поэтому ответ быстро читается и легко ложится в плоскую строку базы данных или одну строку лога.
ipinfo.io сжимает два часто используемых вместе значения в одиночные строки: поле loc содержит широту и долготу вместе в виде строки через запятую, а поле org объединяет номер автономной системы и название организации в одной строке, например номер AS, за которым следует название компании. Это удобно для логирования и быстрого отображения, но требует операции разбиения, прежде чем любое из значений можно будет использовать как настоящее число или сравнивать программно.
ipstack идёт в обратном направлении, к большей структурированности. Он возвращает поля верхнего уровня, такие как type, continent_code, latitude и longitude, как отдельные значения, а сведения о сети и провайдере группирует во вложенный объект connection, а не в плоскую строку. Это подходит приложениям, которым нужно обрабатывать эти сведения как отдельную самостоятельную часть данных.
Ни одна из этих трёх структур не лучше объективно: они отражают разные предположения о том, как вызывающая сторона будет использовать данные. Под плоскую структуру быстрее писать разовый код разбора. Компактная структура с объединёнными строками удобна для конвейеров логирования, которые хранят одну строку на запрос. Вложенная структура держит связанные поля вместе для приложений, строящих более сложную внутреннюю модель данных.
My Geocode поддерживает совместимые хосты для всех трёх этих структур: плоские поля ip-api на /compatibility/ip-api/, компактные строки loc и org от ipinfo на /compatibility/ipinfo/ и вложенный объект connection от ipstack на /compatibility/ipstack/. Это значит, что подобное сравнение не обязано заканчиваться одним победителем для всех: команда может использовать ту структуру, которую уже ожидает её код, или даже протестировать несколько структур на одних и тех же данных поиска во время оценки, поскольку все три хоста работают на одной платформе с одинаковыми вариантами аутентификации и одинаковыми ценами.
Поскольку определение IP здесь полностью работает от начала до конца, а не только воспроизводит формат, это сравнение можно проверить напрямую: направьте небольшой скрипт на все три совместимых хоста с одними и теми же тестовыми IP-адресами и сравните реальную структуру вывода, которую получит ваш собственный код разбора. Аутентификация на любом из них принимает заголовок X-API-Key, Authorization: Bearer, HTTP Basic auth или параметр запроса, а 2 500 бесплатных запросов в день доступны без ключа на любом из трёх, поэтому сравнить структуры бок о бок перед выбором одной из них почти ничего не стоит.