Каждый запрос к My Geocode проходит через одну и ту же обслуживающую инфраструктуру, прежде чем вернётся ответ, независимо от того, на какой эндпоинт он направлен и под какой совместимый хост сформирован. Недавно мы завершили модернизацию этой общей инфраструктуры, и в результате время отклика сократилось повсеместно.
Это изменение касается всей платформы, а не какого-то одного эндпоинта. /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete и /v1/postcode работают на одном и том же модернизированном стеке, как и все семнадцать совместимых хостов. В рамках этого не изменились ни параметры запросов, ни поля ответов, ни способы аутентификации, ни цены. Модернизация полностью скрыта от глаз и заметна только по тому, как быстро приходит ответ.
В большинстве интеграций такое улучшение скорее ощущается, чем точно измеряется: возникает общее ощущение, что вызовы возвращаются чуть быстрее, чем раньше. В интеграциях со значительным объёмом, особенно в пакетных задачах, последовательно обрабатывающих множество элементов, или во всём, где трафик в стиле автодополнения отправляется многократно по мере ввода текста пользователем, эффект накапливается на множестве запросов и становится заметнее напрямую. Поле автодополнения, которое отправляет запрос на каждое нажатие клавиши при вводе поискового запроса из восьми символов, делает восемь вызовов за то время, пока его набирают, и даже небольшое ускорение каждого из них меняет ощущение от всего взаимодействия так, как одиночный отдельный запрос не показал бы вовсе.
Мы относимся к такой работе с инфраструктурой как к постоянной обязанности, а не как к разовому проекту. API геокодирования, на котором люди строят реальные продукты, должен сохранять хорошую производительность по мере роста нагрузки, а не только в день запуска, и это значит, что стек обслуживания нужно периодически пересматривать, а не оставлять нетронутым на неопределённый срок. Это обновление лишь один шаг в продолжающемся процессе, а не конечная точка.
Поскольку каждый эндпоинт и каждый совместимый хост работают через один и тот же общий стек, такое обновление достаточно выполнить один раз, чтобы оно пошло на пользу всем, а не повторять его эндпоинт за эндпоинтом или хост за хостом. Именно благодаря этой общей архитектуре изменение здесь никогда не затрагивает форматы запросов, поля ответов или механизм квот: они находятся на совершенно другом уровне.
Механика квот и оплаты при этом никак не меняется. Каждый ответ по-прежнему содержит тот же полный набор заголовков квоты, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit и X-Quota-Reset, а бесплатные лимиты, тариф предоплаченного баланса и цена пакета Unlimited остаются прежними.
На том же общем стеке работает и каждый совместимый хост, поэтому вызов в формате TomTom и нативный вызов /v1/forward получают одинаковый прирост, и это улучшение не нужно запрашивать для каждого хоста отдельно или отдельно согласовывать для конкретной интеграции.
Если ваша интеграция чувствительна ко времени ответа, потому ли, что она обращена к пользователям, или потому, что обрабатывает большие объёмы пакетных запросов, вы должны заметить разницу, ничего не меняя на своей стороне. Полная документация по каждому эндпоинту осталась точно такой же, как была, и доступна по адресу /docs/.