Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Открытые данные о часовых поясах не должны быть премиум-функцией
База данных часовых поясов IANA публична. Её открыто поддерживают уже несколько десятилетий, отслеживая каждое изменение смещения, правила перехода на летнее время и пересмотр границ, которые вводят правительства. Почти каждый серьёзный сервис определения часового пояса в интернете, включая наш, построен на этом же публичном наборе данных. Поэтому когда API берёт отдельную премиальную плату именно за определение часового пояса сверх того, что уже берёт за геокодирование, стоит спросить, за что именно платится эта надбавка.
Иногда ответ вполне обоснован: время инженеров, которое уходит на поддержание точного соответствия между координатами и границами часовых поясов по мере того, как эти границы смещаются, и инфраструктура для обслуживания запросов в больших масштабах. Это реальная работа, и она чего-то стоит. Менее обосновано другое: относиться к данным о часовых поясах как к отдельной продуктовой линейке с собственным тарифом, цена которого намного выше предельной стоимости одного запроса, потому что их можно встроить в процесс, который клиенту и так нужен, и он вряд ли станет искать им замену отдельно.
Мы не выделяем часовые пояса в премиальное дополнение. Это один эндпоинт из нескольких, и стоит он так же, как любой другой: покрывается бесплатной дневной квотой, а сверх неё оплачивается по тем же 0,0001 € за запрос, что и всё остальное, или входит в тот же ключ Unlimited за 50 €. Нет ни отдельного тарифа для часовых поясов, ни наценки за вопрос о том, который час в заданных координатах.
Определение часового пояса важнее, чем можно подумать по его неброскому названию. От его правильности зависят системы планирования, конвейеры журналирования, платформы бронирования и всё, что должно показывать пользователю правильное местное время. Ошибитесь, и приглашение на встречу сдвинется на час, метка времени в журнале введёт в заблуждение при расследовании, а окно доставки пообещает не тот местный час. Именно такой запрос должен быть дешёвым и скучным, а не строкой, которая неожиданно раздувает счёт.
Отчасти определение часового пояса у других считают премиум-функцией потому, что переходы на летнее время и изменения границ делают исходные данные сложнее на вид, чем статичные коды стран. Эти данные действительно кропотливо поддерживать. Но кропотливость поддержки не то же самое, что высокая стоимость обслуживания одного запроса, и цена должна отражать второе, а не сложность первого.
Премиальная плата за данные о часовых поясах также создаёт плохой стимул на уровне проектирования API: провайдеры перестают хотеть предоставлять их напрямую и начинают упаковывать их в более крупные и дорогие комплекты, исходя из того, что на функцию, цену которой никто не может проверить отдельно, проще сделать наценку. Мы считаем, что противоположный подход вызывает больше доверия. Сделайте эндпоинт простым, установите на него ту же цену, что и на всё остальное, и позвольте разработчикам использовать его ровно так часто, как нужно их приложению, без мысленных подсчётов о том, не относится ли этот конкретный запрос к дорогим.