Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Почему мы не стали начинать с браузерного SDK
Браузерный SDK легко попросить, но для многого из того, что на самом деле делает API геокодирования или определения IP, это действительно плохая идея. Определение местоположения по IP-адресу имеет смысл именно потому, что происходит на сервере, где виден реальный источник запроса. Перенесите тот же запрос в клиентский JavaScript, который выполняется в браузере посетителя, и интеграция не станет удобнее. Вы просто переместите API-ключ для аутентификации в единственное место на всём пути запроса, где любой может открыть инструменты разработчика и прочитать его.
Поэтому мы не ставили браузерный SDK выше поддержки простого HTTP и совместимых хостов. Ключ, переданный в заголовке X-API-Key, как Bearer-токен, через HTTP Basic auth или в параметре запроса, одинаково работает на каждом хосте и вызывается оттуда, где уже находится ваш серверный код: из бэкенд-сервиса, serverless-функции, пакетного задания, откуда угодно, где у запроса уже есть причина исходить из инфраструктуры, которой вы управляете, а не из вкладки браузера, которой вы не управляете.
Геолокация по IP имеет смысл только на стороне сервера. Вся ценность запроса в том, чтобы определить реальный IP-адрес, с которого пришёл запрос, а для большинства значимых сценариев (проверки на мошенничество, локализация, аналитика, которую вы ведёте для себя, а не продаёте) это должно происходить там, где этот IP-адрес достоверен: на вашем сервере, который получает запрос напрямую, а не в браузерной среде, где «IP», о котором сообщил бы клиентский вызов, либо не имеет значения, либо легко подделывается.
Геокодирование введённого адреса не так однозначно относится только к серверу, и есть реальный довод в пользу того, чтобы автодополнение адресов работало отзывчиво прямо в форме, в браузере, без предварительного обращения к вашему бэкенду. Мы не против того, чтобы такой подход со временем появился. Мы против того, чтобы строить его как первый и основной способ интеграции раньше простого серверного доступа по HTTP, который на самом деле нужен большинству реальных сценариев (оформление заказа, калькуляторы доставки, проверки на мошенничество) и который не требует раскрывать учётные данные публично.
В более широком смысле мы возражаем против того, чтобы считать «наличие браузерного SDK» обязательным пунктом для любого API, независимо от того, имеет ли смысл клиентский доступ к данным именно такого рода. Для запроса, где весь смысл в серверном контексте, браузерный SDK в основном отвечает на маркетинговый вопрос «выглядит ли это современно и удобно» ценой реального вопроса безопасности «где в итоге окажутся эти учётные данные». Мы предпочитаем сначала ответить на вопрос безопасности, а удобство пусть следует за ним, а не наоборот.
Всё это не исключает появления со временем более лёгкого инструмента для браузера, рассчитанного именно на случаи, где клиентское использование действительно оправдано, например автодополнения в форме, которому для работы никогда не нужны настоящие учётные данные вашего аккаунта. Но это не должно быть первым, чему мы просим клиента доверять, раньше простого пути через HTTP, который уже безопасно покрывает большинство реальных интеграций.