Зачем придумали 429 Too Many Requests?

Почему сервер иногда отвечает 429 Too Many Requests, хотя с ним всё в порядке? На первый взгляд этот HTTP-код выглядит как обычная ошибка: слишком много запросов - сервер отказал. Но 429 появился именно для другой ситуации: клиент продолжает обращаться к работающему серверу чаще, чем тот готов это позволить. И здесь возникает интересная деталь - почему для этого понадобился отдельный код, если в HTTP уже был 503 Service Unavailable?

Сервер может работать нормально

Представим API интернет-магазина. Тысячи клиентов спокойно получают данные о товарах, а один скрипт начинает отправлять запросы один за другим - без пауз и ограничений.

Сервер ещё справляется. Но если продолжать в таком темпе, один клиент может занять заметную часть его ресурсов.

В этот момент серверу нужно сообщить что-то точнее, чем просто «сервис недоступен».

Поэтому и появляется:

HTTP/1.1 429 Too Many Requests

Смысл простой: сам запрос нормальный, но сейчас таких запросов слишком много.

Почему 503 для этого не совсем подходит

503 Service Unavailable говорит о состоянии сервиса. Например, приложение перегружено или временно находится на обслуживании.

При 429 ситуация может быть совершенно другой.

API продолжает отвечать остальным пользователям. Ограничение действует только для определённого клиента, IP-адреса, API-ключа или другого идентификатора.

И это уже две разные проблемы.

Одно дело - сервер не может обслуживать запросы.

Другое - сервер может, но конкретный клиент слишком быстро расходует доступный ему лимит.

Именно такую ситуацию HTTP и научился обозначать кодом 429.

Откуда вообще берётся лимит

Никакого универсального правила вроде «100 запросов - и получите 429» не существует.

Лимит устанавливает сам сервис.

Где-то это 10 запросов в секунду. Где-то - несколько тысяч в час. Для разных пользователей ограничения могут отличаться.

Поэтому 429 сам по себе не говорит, сколько запросов было отправлено и какой именно предел сработал.

Иногда причина вообще находится не там, где её ищет пользователь. Например, несколько устройств могут выходить в интернет через один IP, а сервис считает лимит именно по нему.

Сервер иногда подсказывает, когда вернуться

Вместе с 429 можно получить заголовок Retry-After:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Здесь сервер предлагает повторить запрос через 60 секунд.

Для API это особенно полезно. Иначе программа может попасть в глупую петлю: получить 429, сразу повторить запрос, снова получить 429 и продолжать делать то же самое.

Retry-After позволяет серверу самому задать паузу.

Почему этот код стал нужен именно тогда

429 стандартизировали в 2012 году, когда интернет уже давно перестал быть просто набором веб-страниц.

Программы начали постоянно обращаться к программам.

API, мобильные приложения, фоновые задачи, автоматические скрипты - все они способны отправлять запросы намного быстрее человека.

Для браузера пользователя разница между десятью и сотней запросов может быть незаметна.

Для сервера - совсем нет.

Поэтому ограничение частоты стало обычной частью работы веб-сервисов, а HTTP получил отдельный код для этой ситуации.

Так что означает 429?

Если совсем коротко: *429 Too Many Requests означает, что клиент обращается к серверу слишком часто и временно упёрся в установленный лимит.**

Сервер при этом необязательно перегружен. Он может прекрасно работать для всех остальных.

И в этом как раз весь смысл 429.

Это не сообщение «сервер умер».

Скорее, сервер говорит:

«Сделай паузу. Потом продолжим».