Тест на знание HTTP-методов и кодов ответов: проверьте базу по REST API
Вопрос «какой код возвращает POST?» плохо проверяет знание HTTP: метод сам по себе не определяет единственный результат. Для осмысленного теста нужны условия — что запросили, что сделал сервер и какое представление возвращается. Ниже можно проверить базу по HTTP-части REST API без угадывания привычек конкретного проекта.
Все мини-кейсы авторские. Они опираются на семантику RFC 9110 и описания MDN, но не изображают реальные запросы к работающему сервису. Контракт учебного API указан там, где без него допустимы разные решения.
Пять различий перед тестом
GET запрашивает представление ресурса. POST передаёт данные для обработки ресурсом; создание — частый, но не единственный случай. PUT создаёт ресурс по выбранному целевому URI либо заменяет его представление. PATCH задаёт частичные изменения. DELETE запрашивает удаление целевого ресурса. RFC 9110 уточняет: запрос не обязательно уничтожает связанную с ресурсом информацию в хранилище; детали зависят от реализации сервера.
Безопасный метод не запрашивает изменения состояния сервера. Логи и статистика при чтении не отменяют безопасную семантику GET. Идемпотентность означает одинаковый предполагаемый эффект одного и нескольких одинаковых запросов, а не обязательное совпадение каждого ответа.
GET безопасен и идемпотентен. PUT и DELETE идемпотентны, но не безопасны. Для POST и PATCH идемпотентность не гарантируется общей семантикой метода. Отдельный API может предусмотреть специальный механизм, но его надо проверить по контракту.
| Код | Короткий смысл |
|---|---|
| 200 OK | Запрос успешно выполнен; смысл содержимого зависит от метода |
| 201 Created | Запрос выполнен с созданием нового ресурса или ресурсов |
| 204 No Content | Успех без содержимого ответа |
| 400 Bad Request | Сервер не может или не хочет обработать запрос из-за воспринимаемой ошибки клиента |
| 401 Unauthorized | Для целевого ресурса нет действительных аутентификационных данных |
| 403 Forbidden | Сервер понял запрос, но отказывается его выполнять |
| 404 Not Found | Представление целевого ресурса не найдено либо сервер не раскрывает его существование |
Вопросы: сначала выберите ответы
1. Чтение карточки
Нужно получить текущую карточку товара без запрошенного изменения данных. Какой метод соответствует задаче? А — GET. Б — DELETE. В — PUT.
2. Создание через PUT
Клиент отправил PUT на заранее выбранный URI, по которому ресурса ещё нет. Сервер действительно создал его и завершил запрос. Какой код соответствует этому результату по семантике PUT? А — 201. Б — 404. В — 401.
3. Явный успех без содержимого
Обновление завершено, возвращать представление не требуется. Какой код прямо сообщает об успехе без содержимого? А — 204. Б — 400. В — 201.
4. Один метод — несколько исходов
Верно ли утверждение «любой успешный POST обязан возвращать 201»? А — да. Б — нет, результат зависит от выполненной операции.
5. Нет действительных учётных данных
Контракт требует аутентификации, а запрос поступил без действительных данных. Какой код отражает эту ситуацию? А — 401. Б — 204. В — 200.
6. Доступ запрещён
Сервер распознал пользователя, но роль не разрешает действие. В этом API существование ресурса не скрывается. Какой код подходит? А — 403. Б — 201. В — 204.
7. Два ответа на DELETE
Первое удаление вернуло 204. Повтор того же DELETE вернул 404: ресурс уже отсутствует. Доказывает ли различие ответов нарушение идемпотентности? А — да. Б — нет, важен предполагаемый эффект на состояние.
8. Частичное изменение счётчика
В условном контракте PATCH означает «увеличить счётчик на один». Можно ли повторять запрос без изменения результата только потому, что это PATCH? А — да. Б — нет.
9. Ошибка формата или отсутствие объекта
Синтаксис запроса корректен, но целевая карточка с указанным идентификатором не существует. Какой базовый код соответствует этому условию? А — 404. Б — 400 только потому, что число отсутствует в базе. В — 201.
10. Проверка только по статусу
Тест получил 200 и сразу завершился успешно. Достаточно ли этого, чтобы подтвердить весь контракт ответа карточки? А — да. Б — нет, нужны проверки содержания и условий сценария.
Разбор ответов
1 — А. Для чтения используется GET. Если сервер по GET оформляет заказ, проблема в реализации маршрута, а не в определении безопасного метода. Побочные технические записи, например журнал доступа, не равны запрошенному изменению бизнес-данных.
2 — А. PUT умеет не только заменять, но и создавать ресурс по целевому URI. Для успешного создания RFC 9110 предусматривает 201. Ошибка новичка — считать, что создавать может исключительно POST, а PUT обязан вернуть один и тот же код в любом случае.
3 — А. 204 означает отсутствие содержимого. Не добавляйте к нему обязательную проверку JSON-тела: такой тест противоречил бы смыслу ответа. Для успешного изменения существующего ресурса PUT также может использовать 200, если возвращается соответствующий результат; условия вопроса здесь специально выбраны для 204.
4 — Б. POST может успешно обработать данные и вернуть 200, создать ресурс с 201 или принять действие для ещё не завершённой обработки с 202. Нельзя выбрать код, не понимая результата. При этом 202 не означает, что длительная операция уже завершилась успешно.
5 — А. 401 относится к отсутствию действительных данных аутентификации. По RFC ответ 401 должен содержать WWW-Authenticate с соответствующим challenge. Название Unauthorized легко вводит в заблуждение: запоминать только русский перевод недостаточно.
6 — А. В заданном контракте отказ в разрешении отражает 403. Но фраза «403 бывает только у авторизованного пользователя» слишком узкая: общее определение — сервер понял запрос и отказывается выполнять. Кроме того, стандарт разрешает скрыть существование запрещённого ресурса через 404, поэтому это условие явно исключено в вопросе.
7 — Б. После первого и повторного DELETE ожидаемый эффект один: ресурса больше нет. Разные коды, время обработки или запись нового обращения в лог не делают метод неидемпотентным. Проверять нужно состояние и контракт, а не побайтовую одинаковость ответа.
8 — Б. Два увеличения дают другой итог, чем одно. PATCH не получает гарантию идемпотентности автоматически. Иной PATCH, например присваивание полю согласованного фиксированного значения, может быть спроектирован идемпотентно; это свойство конкретной операции.
9 — А. Условие говорит об отсутствии ресурса, а не о неразбираемом запросе. Для неверной структуры или другой воспринимаемой ошибки клиента может применяться 400. Не превращайте все неприятные исходы в один общий код «что-то не так».
10 — Б. Проверьте обязательные поля, типы, соответствие запрошенному ID и значимые правила содержимого. HTTP-успех не доказывает правильность данных. Для операций изменения дополнительно проверяют их эффект, а для отрицательных сценариев — предусмотренную ошибку.
Как составлять собственные вопросы
Авторский шаблон хорошего кейса: исходное состояние, метод и цель, результат обработки, требуемый ответ. Если хотите проверить 401 и 403, заранее определите состояние аутентификации и право действия. Если спрашиваете про 200 и 204, укажите, предполагается ли содержимое.
Для практики заведите маленький ресурс «задача»: прочитайте его, создайте по известному URI, замените, частично измените и удалите. До выполнения запишите ожидаемые состояния и ответы по контракту учебного сервиса. Не отправляйте изменяющие запросы в чужое рабочее API ради проверки теории.
После теста полезнее разобрать каждую ошибку словами, чем получить один итоговый балл. Уверенное знание HTTP проявляется в способности объяснить, какие условия делают ответ правильным, а не в запоминании пары «метод — единственный код».
