Если два раза вызвать метод GET, будет ли сервер реагировать на второй запрос

Что проверяют

Понимаете ли вы, что идемпотентность и безопасность методов HTTP это обещание спецификации, а не гарантия реализации, и умеете ли это проверить. Следом обычно спрашивают, чем идемпотентность отличается от безопасности и какие из POST, PUT, DELETE идемпотентны.

Как отвечать

Короткий ответ: да, сервер обработает второй запрос как самостоятельный. HTTP не хранит состояние между запросами, и сервер не «помнит», что такой запрос уже был. Вопрос в том, каким будет результат.

• безопасный метод: по RFC 9110 GET не должен менять состояние ресурса, клиент вправе повторять его без последствий;
• идемпотентный: повтор даёт на сервере тот же эффект, что и один вызов. Это GET, HEAD, OPTIONS, PUT, DELETE, а POST и PATCH нет;
• ответ может отличаться: данные поменял кто-то другой, в ответе есть время или счётчик, сработал rate limit и пришёл 429;
• кеш: второй запрос может не дойти до сервера, если ответ отдал браузер, CDN или прокси по Cache-Control. На условный запрос с If-None-Match сервер ответит 304 Not Modified без тела.

Для тестировщика главное, как это проверить. Отправьте запрос дважды в Postman или автотестом и сравните статус, тело и состояние данных в базе или соседних эндпоинтах. В логах или Kibana посмотрите, дошли ли оба запроса. Отдельно ищите нарушение контракта: GET, который увеличивает счётчик просмотров, ещё допустим, а GET /orders/1/cancel, отменяющий заказ, это баг. Такую ссылку однажды откроет краулер или предзагрузка в браузере, и заказы отменятся сами.

Где спотыкаются

Отвечают «нет, второй запрос сервер проигнорирует», путая идемпотентность с дедупликацией. Сервер обработает оба, идемпотентность говорит только об одинаковом эффекте.

Считают, что идемпотентность значит одинаковый ответ. DELETE идемпотентен, но первый вызов вернёт 204, а второй 404, и это нормально.

Проверяют только код ответа. Изменение состояния видно в базе, в соседнем эндпоинте или в логах, а не в статусе 200.