Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Скрытая цена привязки к поставщику
Никто не подключается к API с намерением оказаться к нему привязанным. Привязка не появляется в виде пункта договора, от которого можно отказаться на переговорах. Она накапливается, одно удобство за другим, пока стоимость перехода незаметно не превысит стоимость той проблемы, из-за которой вы вообще задумались о переходе.
Всё начинается с малого. Вы устанавливаете SDK провайдера, потому что он экономит несколько часов на ручном написании HTTP-вызовов. Вы сохраняете структуру объекта ответа прямо в базе данных, вместо того чтобы отображать её на собственную схему, потому что тогда это отображение казалось лишней работой. Вы строите обработку ошибок вокруг конкретных кодов статуса провайдера, а не вокруг общей схемы. Каждое из этих решений по отдельности разумно в моменте, при обычном давлении сроков. Ни одно из них не принимается с мыслью о привязке. Все они её усиливают.
Спустя годы провайдер повышает цены, или у него случается сбой в загруженный период, или он просто перестаёт быть лучшим вариантом для функции, которая вам теперь нужна. Переход должен сводиться к выбору нового поставщика и изменению одного значения в конфигурации. Вместо этого он превращается в проект: переписывание логики разбора, разбросанной по кодовой базе, перестройка обработки ошибок, переобучение внутренних инструментов, которые выросли вокруг старой структуры. Стоимость перехода никогда не выставлялась в счёте. Она была оплачена заранее, небольшими решениями при интеграции, которые в то время никто не отмечал как рискованные.
Мы создали совместимые хосты именно против этой закономерности. Если ваша интеграция уже использует структуру запросов и ответов другого провайдера, то для того, чтобы направить её на один из наших 17 совместимых хостов, не требуется заранее планировать переносимость. Вы получаете возможность уйти, не проявив в своё время предусмотрительности и не готовясь к уходу. Это существенное отличие от большинства советов по борьбе с привязкой, которые обычно звучат как «с первого дня стройте всё поверх слоя абстракции»: хороший совет, которому под давлением сроков почти никто на самом деле не следует.
Аутентификация является меньшим примером того же принципа. Некоторые провайдеры подталкивают вас к одному определённому методу аутентификации, привязывая вашу интеграцию к конкретной клиентской схеме. Мы принимаем ключ в заголовке X-API-Key, в заголовке Authorization Bearer, через HTTP Basic auth или в параметре запроса, на каждом хосте и без доплаты за любой из этих способов. Какую бы схему ваш существующий код ни использовал для других API, наша, скорее всего, ей подходит, так что вам не придётся переписывать слой аутентификации только ради того, чтобы попробовать нас.
Честная причина, по которой привязка сохраняется в этой отрасли, в том, что с коммерческой точки зрения она работает. Клиент, который ушёл бы только из-за цены, часто остаётся, потому что уход означает переписывание кода. Мы считаем, что строить бизнес на такой сделке плохо, потому что так удерживаются уже недовольные клиенты, а не те, кто действительно доволен. Если уйти остаётся дёшево, то оставшиеся клиенты остаются потому, что продукт по-прежнему того стоит, а не потому, что где-то на втором году дверь к выходу тихо заложили кирпичом.