Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Почему совместимые хосты важнее нового SDK
Каждая API-компания хочет, чтобы вы установили её SDK. SDK привязывает. Как только ваша кодовая база импортирует клиентскую библиотеку, вызывает её методы и зависит от формы её объектов, смена провайдера означает переписывание кода, который общается с провайдером, а не просто замену URL. Такая привязка часто и является настоящей бизнес-моделью бесплатного и удобного SDK, говорит об этом кто-то вслух или нет.
Мы выбрали другой подход. У My Geocode 17 совместимых хостов, и каждый из них воспроизводит формат запросов и ответов другого провайдера. Если ваш код уже умеет вызывать эндпоинт известного API геокодирования и разбирать его JSON, вы можете направить этот же код на наш совместимый хост, и он продолжит работать. Не нужно устанавливать SDK, не нужно переписывать разбор ответов, не нужно изучать проприетарную объектную модель.
Это кажется мелочью, пока вы на самом деле не попробуете перевести production-систему с одного API на другой. URL эндпоинта это простая часть. Сложная часть это каждое место в вашей кодовой базе, которое обращается к конкретному имени поля, обрабатывает конкретный формат ошибки или предполагает конкретный способ пагинации. Такие допущения годами расползаются по кодовой базе, в места, которые никто не вспомнит проверить. Совместимый хост избавляет от необходимости искать и исправлять их, потому что формат не меняется.
SDK, напротив, решает задачу, с которой вы столкнётесь лишь однажды, при первом подключении к API, ценой проблемы, с которой вы будете сталкиваться всё время жизни продукта: привязанности к проектным решениям этого SDK. Когда SDK выпускает несовместимое изменение, его поглощаете вы. Когда перестаёт поддерживаться привязка для языка, на которую вы опираетесь, это тоже поглощаете вы. У обычного HTTP-совместимого хоста ничего этого нет. Это просто URL, который возвращает ответ в формате, который вы уже умеете читать.
Мы не против SDK в целом. Тонкая обёртка, избавляющая вас от написания шаблонного HTTP-кода, это удобство, а не ловушка, если отказ от неё в будущем не превращается в такой же проект, как смена провайдера. Ловушка возникает, когда форматы SDK становятся единственными форматами, которые понимает ваш код, и уход означает переписывание, а не перенастройку.
Создать 17 совместимых хостов было для нас большей работой, чем создать один SDK. Каждый хост должен точно, поле за полем, повторять формат ответа другого провайдера, чтобы существующие интеграции не заметили разницы. Мы проделали эту работу, потому что она переносит стоимость перехода с вашей стороны на нашу. Вы можете проверить, подходят ли вам наши данные, наша доступность и наши цены, не оплачивая сначала интеграцию только ради того, чтобы это выяснить. Посмотрите полный список совместимых хостов или документацию, чтобы узнать, как каждый из них соотносится с оригиналом.
Новый SDK просит разработчика доверять инженерным решениям компании на всё время жизни проекта. Совместимый хост просит гораздо меньшего: заменить базовый URL, возможно API-ключ, и посмотреть, что получится. Это более честный обмен, и именно поэтому мы создали совместимые хосты раньше всего остального.