<<Чек-лист упущенных требований>>
Типовой кейс:
маркетплейс с тысячами товаров.
Пользователь выбрал категорию, цену, бренды и рейтинг, а затем дважды нажал «Показать результаты», потому что на медленном интернете ничего не происходило.
Запрос с Frontend на Backend:
GET /products?category=electronics&brand=Apple&rating=4
или
QUERY /products
// фильтры в JSON-объекте, в body
или
POST /products/search
// фильтры в JSON-объекте, в body
GET и QUERY — безопасные и идемпотентные методы.
POST по своей HTTP-семантике не гарантирует безопасность и идемпотентность, хотя его можно сделать таким искусственно, через требования к алгоритму работы.
Но здесь есть важный момент:
❗️ Идемпотентность не означает, что Backend выполнит два одинаковых запроса только один раз.
Она означает, что повторный вызов не должен привести к дополнительному изменению состояния системы.
Поэтому два одинаковых GET- или QUERY-запроса всё равно могут дважды запустить тяжёлый поиск.
🚩 Результат:
1. Frontend отправил два одинаковых запроса.
2. Backend дважды запустил тяжёлый поиск и фильтрацию.
⚠️ = неоптимальное использование ресурсов Backend
⚠️ = проблемы для высоконагруженной системы
Разработчик говорит:
Пользователь сам дважды нажал. Что мы сделаем?
На самом деле — многое.
🚩 Что упущено в требованиях?
👉 Требования к Frontend:
▫️ После первого нажатия показать состояние «Загрузка» и блокировать повторное нажатие
▫️ Не отправлять повторный запрос, пока выполняется предыдущий запрос с теми же параметрами
▫️ При изменении фильтров отменять предыдущий запрос или игнорировать его устаревший ответ
▫️ Не заменять актуальные данные ответом на более старый запрос, который завершился позднее
👉 Требования к Backend:
▫️ Ограничить частоту запросов от одного пользователя или клиента (rate limiting)
▫️ Кэшировать результаты одинаковых запросов с заданным TTL
▫️ При необходимости объединять одинаковые параллельные запросы, чтобы поиск выполнялся один раз
▫️ Зафиксировать таймауты и максимальное время выполнения поиска
▫️ Логировать повторные запросы и превышение установленных ограничений
❗️ Идемпотентность защищает состояние системы.
✅ Кэширование, дедупликация и rate limiting защищают её ресурсы.
Это разные свойства и разные требования.
Поэтому при проектировании API недостаточно выбрать GET, POST или QUERY. Системный аналитик должен отдельно описать, как Frontend и Backend обрабатывают повторные и параллельные запросы.
Иначе этот алгоритм команда начнёт проектировать уже после первого инцидента в проде.
#RestApiGA