# Лимиты API-запросов (Rate limits)

> **Лимиты API-запросов (Rate limits)** — это механизм контроля и ограничения количества обращений к программному интерфейсу (API) со стороны одного пользователя, IP-адреса или приложения за определенный отрезок времени. Главная цель этого механизма — предотвратить перегрузку сервера и обеспечить стабильную работу сервиса для всех пользователей.

## Зачем нужны Rate limits?

Представьте себе популярную кофейню в утренний час пик. Если один клиент закажет сразу 500 чашек кофе, бариста не сможет обслужить остальных посетителей, и очередь встанет. В мире веб-разработки сервер — это бариста, а клиентские приложения — это посетители. Чтобы один «жадный» скрипт не забрал все ресурсы сервера, вводятся лимиты.

Основные причины использования лимитов API-запросов:

- **Защита от перегрузок и DDoS-атак:** Ограничения не позволяют злоумышленникам или некорректно написанным ботам «положить» сервер огромным количеством бессмысленных запросов.
- **Справедливое распределение ресурсов:** Гарантирует, что вычислительные мощности будут доступны всем пользователям поровну, а не только самым активным.
- **Монетизация и тарификация:** Многие SaaS-платформы продают доступ к своим API. Бесплатный тариф может позволять 100 запросов в день, а платный — 10 000.
- **Контроль расходов:** Облачные инфраструктуры (например, AWS или Google Cloud) берут плату за потребленные ресурсы. Лимиты защищают владельца API от астрономических счетов за сервер.

## Как это работает на практике

Когда приложение обращается к серверу, система учета проверяет, не превышен ли лимит для этого конкретного пользователя (обычно идентификация происходит по API-ключу, токену авторизации или IP-адресу). Если лимит не исчерпан, запрос обрабатывается. Если же лимит превышен, сервер отказывается выполнять задачу.

В этом случае сервер возвращает специальный HTTP-статус: **429 Too Many Requests** (Слишком много запросов). Часто в ответе сервера также передаются специальные заголовки, которые помогают разработчикам понять текущую ситуацию:

- **X-RateLimit-Limit** — максимальное количество запросов, доступное в текущем временном окне.
- **X-RateLimit-Remaining** — сколько запросов еще осталось до блокировки.
- **X-RateLimit-Reset** — время, когда счетчик обнулится и лимит будет восстановлен.

### Популярные алгоритмы Rate Limiting

Для технической реализации лимитов инженеры используют несколько классических алгоритмов. Вот самые распространенные из них:

- **Token Bucket (Алгоритм маркерной корзины):** Представьте ведро, в которое с определенной скоростью падают жетоны (токены). Каждый API-запрос забирает один жетон. Если ведро пустое, запрос отклоняется. Это позволяет обрабатывать кратковременные всплески трафика, пока в ведре есть запас жетонов.
- **Leaky Bucket (Алгоритм дырявого ведра):** Похож на предыдущий, но запросы «вытекают» из ведра строго с постоянной скоростью. Если запросов поступает слишком много и ведро переполняется, новые капли (запросы) просто отбрасываются. Это сглаживает нагрузку на сервер.
- **Fixed Window (Фиксированное окно):** Время делится на жесткие отрезки (например, с 12:00 до 12:01). В каждом окне разрешено определенное количество запросов. Минус алгоритма в том, что если пользователь отправит все запросы в последнюю секунду первого окна и в первую секунду второго, сервер получит двойную нагрузку за короткий миг.

## Примеры использования лимитов

Rate limits встречаются практически в любом современном онлайн-сервисе. Вот несколько понятных примеров:

- **Социальные сети:** API ВКонтакте или Telegram жестко ограничивают количество отправляемых сообщений в секунду для ботов. Это защищает пользователей от спама.
- **Погодные информеры:** Бесплатный виджет погоды на сайте может использовать публичный API (например, OpenWeatherMap), который разрешает делать не более 60 запросов в минуту. Если сайт станет слишком популярным, виджет перестанет показывать погоду до покупки платного тарифа.
- **Парсинг данных:** Если вы попытаетесь скачать все товары с крупного маркетплейса с помощью автоматического скрипта, через пару секунд ваш IP-адрес временно заблокируют сработавшие Rate limits.

## Интересный факт: Как появился статус 429 и при чем тут чайники?

Долгое время в стандартах интернета не было единого способа сказать пользователю «ты отправляешь слишком много запросов». Серверы выкручивались как могли: возвращали ошибку 500 (Внутренняя ошибка сервера), 503 (Сервис недоступен) или даже 400 (Неверный запрос). Это создавало огромную путаницу для разработчиков клиентских приложений.

Лишь в апреле 2012 года инженерная целевая группа интернета (IETF) выпустила документ RFC 6585, который официально ввел код **429 Too Many Requests**. Забавно, что обсуждение этого важного кода шло параллельно с шуточным кодом **418 I'm a teapot** («Я — чайник»), который был придуман еще в 1998 году как первоапрельская шутка для протокола управления кофеварками. Сегодня код 429 — это абсолютный стандарт индустрии, который ежедневно спасает миллионы серверов от «падения», а код 418 так и остался легендарной пасхалкой, которую любят добавлять в свои API разработчики-энтузиасты.