Зачем это спрашивают
Вопрос про методы звучит просто, поэтому его часто задают первым в блоке про API. Интервьюер проверяет не память, а понимание: знаете ли вы, что метод — это договорённость о смысле запроса, и умеете ли из этого смысла выводить проверки. Тестировщик, который понимает идемпотентность, сам догадается проверить двойной клик по кнопке «Оформить заказ» или повтор запроса после обрыва сети. Тот, кто помнит только «GET получает, POST отправляет», такие сценарии пропустит.
Вторая часть — «чем GET отличается от POST» — ловушка на популярный миф о том, что POST «безопаснее». Хороший ответ разводит два значения слова «безопасный»: в терминах HTTP и в терминах защиты данных.
Как построить сильный ответ
Удобная схема из трёх шагов.
1. Перечислите методы и их смысл.
| Метод | Смысл | Безопасный | Идемпотентный |
|---|---|---|---|
| GET | получить представление ресурса | да | да |
| HEAD | то же, что GET, но без тела ответа | да | да |
| POST | обработать данные: создать ресурс, запустить действие | нет | нет |
| PUT | создать или полностью заменить ресурс по адресу | нет | да |
| PATCH | частично изменить ресурс | нет | не обязательно |
| DELETE | удалить ресурс | нет | да |
| OPTIONS | узнать, какие возможности доступны для ресурса | да | да |
Ещё есть TRACE и CONNECT, но в работе тестировщика они встречаются редко; достаточно упомянуть, что они существуют.
2. Объясните два свойства.
- Безопасный метод по RFC 9110 не должен менять состояние сервера по замыслу клиента. GET, HEAD, OPTIONS и TRACE — безопасные.
- Идемпотентный метод при повторе того же запроса оставляет сервер в том же состоянии, что и после первого. Идемпотентны все безопасные методы, а также PUT и DELETE. POST — нет. PATCH — зависит от того, как устроено изменение.
Сразу добавьте, почему это важно на практике: клиенты, прокси и браузеры могут автоматически повторять идемпотентные запросы при сбое соединения, а повтор POST без защиты на сервере способен создать дубль.
3. Сравните GET и POST по существу.
- GET передаёт параметры в строке запроса, POST — обычно в теле.
- Ответы на GET по умолчанию могут кэшироваться браузером и прокси, ответы на POST на практике почти никогда не кэшируются.
- GET-адрес можно сохранить в закладки, переслать, он остаётся в истории браузера и в логах серверов. Поэтому пароли, токены и персональные данные в параметрах GET передавать нельзя.
- POST не шифрует данные. Защищает их TLS, то есть HTTPS, и он одинаково защищает и строку запроса, и тело при передаче. Разница в том, где данные потом оседают.
- Длина адреса ограничена на практике серверами и браузерами, тело запроса — гораздо меньше.
GET /api/products?category=shoes&sort=price HTTP/1.1
Host: <домен магазина>
POST /api/orders HTTP/1.1
Host: <домен магазина>
Content-Type: application/json
{"items": [{"productId": 3, "qty": 1}]}
Пример ответа
Основные методы — GET, POST, PUT, PATCH и DELETE, ещё есть HEAD и OPTIONS. GET получает ресурс, POST создаёт ресурс или запускает действие, PUT заменяет ресурс целиком, PATCH меняет его частично, DELETE удаляет. Я всегда держу в голове два свойства. Безопасные методы — GET, HEAD, OPTIONS — не должны менять данные. Идемпотентные — это безопасные плюс PUT и DELETE: если повторить запрос, состояние сервера не изменится. POST не идемпотентен, поэтому я обязательно проверяю повторную отправку формы и двойной клик — не появится ли второй заказ. Разница GET и POST не в безопасности: данные защищает HTTPS. Но параметры GET остаются в истории браузера и логах, поэтому пароли и личные данные туда класть нельзя. Ещё ответы на GET кэшируются, а на POST — нет.
Частые ошибки
- Называть POST идемпотентным или говорить, что PUT и POST «одно и то же, просто разные названия».
- Утверждать, что POST «безопаснее, потому что данные скрыты». В DevTools тело POST видно так же, как и строка запроса.
- Путать идемпотентность с одинаковым ответом. Повторный DELETE может вернуть 404 — метод при этом остаётся идемпотентным.
- Говорить, что GET «вообще не может» менять данные. Может, если так написал разработчик, — и это дефект проектирования, о котором стоит сообщить.
- Отвечать только определениями без единого примера проверки.
Пример на MarketCove
Представьте, что вы проверяете оформление заказа в учебном магазине MarketCove. Откройте Swagger на /api/docs и посмотрите, какие методы поддерживают эндпоинты.
GET /api/productsиGET /api/products/{id}— безопасные. Вызовите их несколько раз подряд: данные каталога не должны меняться, а ответ должен быть одинаковым.- Оформление заказа через
/api/shop/orders— это создание ресурса, обычно POST. Здесь главный вопрос: что будет, если отправить тот же запрос дважды? Подумайте, какое поведение ожидаете: второй заказ, ошибку или защиту от дубля. Затем проверьте черезGET /api/ordersили историю в профиле, сколько заказов появилось на самом деле. - Попробуйте вызвать эндпоинт неподдерживаемым методом, например DELETE на каталог. Ожидаемо получить 405 Method Not Allowed, а не 500. Подробнее о кодах — в статье про коды ответа HTTP.
- Проверьте в DevTools на вкладке Network, какие запросы уходят при входе. Если логин или токен передаются в строке адреса, это повод для баг-репорта.
Задание для практики
Откройте API-песочницу или Swagger магазина и составьте таблицу из трёх столбцов: эндпоинт, метод, что произойдёт при повторе запроса. Для каждого POST запишите, как вы проверите отсутствие дублей и через какой GET убедитесь в результате. Потом проговорите вслух ответ на вопрос «чем PUT отличается от PATCH» с примером изменения профиля — уложитесь в минуту. Если хотите проверить себя на скорость, пройдите блиц.
