Можно ли методом GET создавать ресурсы в HTTP
Что проверяют
Понимаете ли вы разницу между «протокол не даст» и «так делать нельзя», и знаете ли, что такое безопасные и идемпотентные методы. Тестировщику следом задают практический вопрос: как проверить, что GET в API ничего не меняет.
Как отвечать
Технически можно: сервер обработает GET как угодно, HTTP этому не мешает. Но это нарушение семантики с предсказуемыми последствиями:
- безопасность метода: по RFC 9110 GET безопасный, клиент им не просит менять состояние. На это полагаются все вокруг: браузеры предзагружают ссылки, поисковые роботы их обходят, мессенджеры открывают ради превью. Каждый такой заход создаст запись;
- идемпотентность: GET идемпотентен, поэтому клиенты, прокси и библиотеки вправе сами повторить его при обрыве соединения. Получите дубли;
- кэширование: ответ на GET может прийти из кэша браузера или CDN, и запрос вообще не дойдёт до сервера;
- данные в URL: параметры создания попадают в историю браузера и логи серверов, а ссылку можно подсунуть в
<img src>и получить CSRF.
Хороший живой пример: ссылки «отписаться» в письмах. Почтовые сканеры открывали их сами и отписывали людей без их ведома, поэтому отписка в один клик по RFC 8058 делается POST-запросом.
Что проверить как QA: повторить GET несколько раз и сравнить состояние до и после; запрос к эндпоинту создания методом GET должен получить 405 Method Not Allowed с заголовком Allow; у GET проверить заголовки кэширования. Создают ресурс через POST, а PUT подходит, когда клиент сам знает адрес ресурса.
Где спотыкаются
Отвечают «нет, GET не может создать ресурс». Может, запрет смысловой, а не технический, и интервьюер ждёт именно этого различия.
Путают безопасность и идемпотентность. PUT и DELETE идемпотентны, но не безопасны, а POST ни то ни другое.
Приводят устаревшую цифру про 2048 символов в URL. Это ограничение старого Internet Explorer, а RFC 9110 рекомендует поддерживать URL длиной не меньше 8000 байт.