Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Лимиты запросов должны быть задокументированы, а не обнаружены
Бывает особенно неудачное утро, которое начинается со всплеска неудачных запросов и заканчивается тем, что разработчик впервые читает страницу статуса провайдера, пытаясь понять, сбой это или лимит, о существовании которого он даже не знал. Такого утра можно полностью избежать, и то, что в отрасли оно до сих пор случается, это провал документации, а не инфраструктуры.
Лимит запросов не секрет. Это эксплуатационная характеристика системы, такая же, как максимальный размер запроса или поддерживаемый метод HTTP, и ей место там же: в письменном виде, до того как кто-то в неё упрётся. Мы публикуем свои лимиты в документации по лимитам запросов, рядом со страницами аутентификации и ошибок, чтобы цифры, которые разработчику нужно учитывать при планировании, были доступны до того, как он напишет первую строку кода интеграции, а не после первого дня, похожего на сбой.
Однако одной документации недостаточно, потому что лимиты могут зависеть от вашего тарифа, а документ устаревает в тот момент, когда меняется статус вашего аккаунта. Поэтому каждый ответ также содержит актуальные заголовки квоты: ваш лимит, сколько вы уже использовали, сколько осталось бесплатной квоты, какая часть общей квоты вашей сети израсходована, остаток предоплаченного баланса и время сброса квоты. Не нужно сверять документ с личным кабинетом, чтобы понять, где вы находитесь. Ответ приходит вместе с самим ответом API, при каждом вызове.
Некоторые провайдеры считают опубликованные лимиты конкурентной слабостью, которую нужно скрывать, исходя из того, что видимая цифра побуждает клиентов торговаться или сравнивать её с конкурентом. Мы считаем, что этот инстинкт ошибочен. Лимит, который никто не видит, ничуть не лучше защищает инфраструктуру провайдера. Он лишь означает, что клиент впервые узнает реальную цифру, когда уже её превысил, в самый неудачный момент для растущего продукта, на глазах у собственных пользователей.
Кроме того, документирование лимитов заранее приучает провайдера к дисциплине проектирования. Если лимит запросов будет опубликован, это должна быть реальная цифра, за которую кто-то готов отвечать, а не размытый внутренний порог, который тихо меняют всякий раз, когда он становится неудобным. Записать цифру и отдавать её в заголовках ответа при каждом вызове значит, что лимит должен действительно быть лимитом, стабильно, а именно это свойство и нужно разработчику.
Узнать о лимите запросов из-за неудачного запроса в продакшене это не обряд посвящения. Это признак того, что документация не справилась со своей задачей. Наша документация нужна для того, чтобы о таком неудачном утре вы читали как о случае с кем-то другим, а не переживали его сами.