Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Почему API только с вебхуками незаметно исключают пакетных пользователей
Вебхук имеет смысл для события, время которого нельзя предсказать: прохождение платежа, изменение статуса отправления, что-то на стороне провайдера, на что ваша система должна реагировать, когда бы это ни произошло. Гораздо меньше смысла в нём как в единственном способе получить ответ на вопрос, который вы задали напрямую и на который ждёте прямого ответа, например определение адреса или поиск часового пояса. Требование завести эндпоинт для вебхука только ради результата синхронного запроса перекладывает реальную инфраструктурную работу на клиента, который, возможно, хочет просто запустить скрипт, дождаться ответа и двигаться дальше.
Особенно остро эта проблема встаёт в пакетных и массовых сценариях. Разработчик, запускающий разовый скрипт, чтобы определить список адресов из таблицы, не хочет поднимать приёмник вебхуков, обрабатывать повторные попытки, если его эндпоинт ненадолго недоступен, и сопоставлять входящие данные вебхуков с исходными запросами, и всё это ради ответов, которые могли бы прийти прямо в ответе на вызов, который их запросил. Доставка только через вебхуки для такой задачи добавляет целый слой инфраструктуры к задаче, которая должна сводиться к одному запросу и одному ответу.
Мы по умолчанию обрабатываем запросы, включая пакетные и массовые, синхронно: вы отправляете запрос и получаете ответ напрямую, содержит ли этот запрос один элемент или тысячу. Использование пакетного эндпоинта никак не требует поднимать публичный приёмник только для сбора результатов. Скрипт, cron-задание или разовая утилита командной строки могут вызвать эндпоинт и сразу использовать ответ, точно так же, как при одиночном запросе.
Дизайн «только вебхуки» обычно вырастает из архитектуры, построенной вокруг асинхронной обработки на стороне провайдера, где крупное пакетное задание действительно занимает внутри заметное время, и вебхук действительно более естественный способ сообщить о завершении. Для некоторых видов крупномасштабной или сильно загруженной очередями обработки это обоснованный подход. Проблемой он становится, когда предлагается как единственный вариант и загоняет каждый сценарий, включая те, где предпочли бы просто немного подождать и получить ответ напрямую, в архитектуру, рассчитанную на другую, более медленную нагрузку.
Мы не против вебхуков как варианта для действительно долгой или асинхронной работы. Мы против того, чтобы делать их обязательными для задач, которым асинхронность вообще не нужна. Скрипт, который хочет отправить тысячу запросов и получить тысячу ответов, должен иметь возможность сделать ровно это, одним вызовом и одним ответом, не строя сначала инфраструктуру для приёма обратного вызова ради задачи, с которой синхронный запрос справился бы так же хорошо и с гораздо меньшим количеством кода.