Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Что решает ограничение запросов на уровне сети, чего не решают лимиты по ключу
Лимит запросов, привязанный только к API-ключу, молчаливо предполагает, что одному ключу соответствует один законный пользователь, использующий его одним достаточно предсказуемым образом. Это допущение нарушается чаще, чем рассчитывает такая схема. Ключ может использоваться всей командой, быть встроен в клиентское приложение, где множество разных посетителей отправляют запросы с одними и теми же учётными данными, или многократно создаваться тем, кто специально пытается сложить несколько ключей, чтобы обойти лимит одного ключа.
Именно поэтому мы ограничиваем запросы не только на уровне ключа, но и на уровне сети. Каждая сеть, один блок /24 для IPv4 или один блок /48 для IPv6, получает бесплатную квоту в 2 500 запросов в день, общую для использования без ключа и для всех ключей, зарегистрированных с адресов этой сети. Нельзя создать десять ключей из одной сети и увеличить свою бесплатную квоту в десять раз, потому что потолок на уровне сети отлавливает такой паттерн независимо от того, сколько отдельных ключей под ним находится.
Речь прежде всего не о пресечении злонамеренных злоупотреблений, хотя и это тоже. Речь о том, чтобы бесплатная квота оставалась значимой для всех, кто пользуется ею честно. Общий ресурс вроде бесплатного тарифа остаётся щедрым, только если эту щедрость не выкачивают незаметно оптом несколько аккаунтов, обходящих лимит по ключу. Квоты на уровне сети держат арифметику бесплатного тарифа ближе к тому, что он на самом деле был задуман выдавать: реальную дневную квоту на источник, а не на каждый ключ, который этот источник держит.
Есть законный сценарий, который при этом нельзя наказывать: несколько настоящих пользователей или сервисов, законно работающих из одной сети, например из офиса, общей хостинговой среды или крупной организации за небольшим числом публичных IP-адресов. Именно поэтому мы публикуем скользящие IP-слоты и показываем использование сети через заголовки квот, включая отдельный заголовок о том, сколько IP-слотов вашего ключа занято относительно лимита. Законная команда, которая делит одну сеть, видит своё реальное положение, а не обнаруживает общий потолок, лишь неожиданно в него упёршись.
Ограничение запросов только на уровне ключа проще построить и объяснить, и для многих API его, вероятно, достаточно. Но для сервиса с заметным бесплатным тарифом ограничение только по ключу оставляет очевидный пробел: бесплатная квота никогда не задумывалась как ресурс, который можно умножить, создавая новые учётные данные, а лимит, который этого не учитывает, на самом деле не защищает то, что обещает защищать. Потолок на уровне сети поверх лимита на уровне ключа закрывает этот пробел, не требуя от каждого законного пользователя доказывать, что он не исключение.