Методы HTTP-запросов GET, POST, PUT, DELETE: примеры для тестировщика
Когда вы открываете сайт, вбиваете адрес в строку браузера и нажимаете Enter — вы отправляете GET-запрос. Когда заполняете форму регистрации и кликаете «Отправить» — скорее всего, улетает POST. Когда редактируете профиль и сохраняете изменения — возможно, PUT. А когда удаляете товар из корзины — DELETE.
Мы делаем это каждый день, даже не задумываясь.
Но если вы учитесь на тестировщика, разница между этими методами — не просто теория, а инструмент диагностики. Вы не сможете понять, что пошло не так в работе сайта, если не знаете, что именно браузер попросил у сервера и как сервер должен был ответить.
HTTP-методы — это язык, на котором браузер общается с сервером. GET, POST, PUT, DELETE — четыре основных глагола этого языка. И каждый говорит серверу: «Сделай вот это».
Для тестировщика понимание методов — это как для механика умение различать, какая кнопка за что отвечает. На первый взгляд все одинаковые, а последствия разные.
Как это выглядит на практике?
Вы открываете инструменты разработчика в браузере — чаще всего это DevTools. Нажимаете F12 или кликаете правой кнопкой по странице и выбираете «Исследовать элемент». Переходите во вкладку Network — там отображаются все запросы, которые браузер отправляет и получает. Кликаете по любому запросу — и видите метод (GET, POST, PUT, DELETE), URL, статус ответа (200, 404, 500), заголовки и тело запроса. Всё это и есть ваш источник данных.
В этой статье разберём четыре основных метода. Без воды, с примерами и с теми нюансами, о которых обычно молчат в кратких шпаргалках. Я сам недавно начал разбираться с HTTP-запросами и знаю, на чём спотыкаются новички.
GET — запрос, который ничего не должен менять
GET — это метод для получения данных. Он говорит серверу: «Дай мне информацию». Никаких изменений на сервере не предполагается.
Вы открываете каталог товаров — GET. Переходите на страницу статьи — GET. Ищете по ключевому слову — тоже GET, только с параметрами в адресной строке.
Важное правило, которое часто нарушают: GET не должен менять состояние сервера. Никаких записей в базу, никаких списаний с баланса, никаких отправок писем.
Почему это так критично? Потому что браузеры и поисковики могут повторять GET-запросы автоматически. Если ваш GET удаляет товар из базы, а пользователь обновил страницу — товар может удалиться дважды, а может и вовсе без подтверждения. Это классический баг, который новички допускают на первых проектах.
В тестировании вы всегда проверяете: приводит ли GET к изменениям в системе? Если да — это нарушение спецификации и потенциальная дыра в безопасности.
POST — создание и отправка данных
POST предназначен для создания новых ресурсов. Вы отправляете на сервер данные, и он на их основе создаёт что-то новое: заказ, пользователя, комментарий.
Пример: вы регистрируетесь на сайте. Вводите логин, пароль, почту — нажимаете кнопку. Данные уходят POST-запросом, сервер создаёт запись в базе и возвращает вам ID нового пользователя.
С POST сложнее с безопасностью и идемпотентностью. Идемпотентность — это когда повторный запрос с теми же данными даёт тот же результат, что и первый. POST не идемпотентен: если вы дважды отправите форму регистрации, может создаться две учётные записи. Поэтому на фронтенде часто блокируют кнопку после первого клика — чтобы избежать дублей.
Тестировщик должен проверить, что POST-запрос действительно создаёт ресурс, а не просто возвращает «успех» без записи в базу. И что он корректно обрабатывает невалидные данные.
PUT — полное обновление ресурса
PUT пришёл для замены целого ресурса. Вы отправляете на сервер полный «слепок» объекта, который должен стать новым состоянием.
Например, у вас есть профиль пользователя с полями: имя, город, телефон. Вы отправляете PUT-запрос с обновлёнными данными. Сервер берёт этот объект и полностью заменяет старый. Если вы не передали какое-то поле — оно может стать пустым или сброситься в значение по умолчанию.
На практике PUT используют реже, чем POST. Часто разработчики делают частичные обновления через PATCH, но это уже отдельная история.
Важный нюанс: PUT требует, чтобы клиент знал полное состояние ресурса. Он не умеет «добавить только телефон». Если вы отправите только номер телефона, а имя не отправите — имя может обнулиться. Это частая ошибка при проектировании API.
DELETE — удаление ресурса
DELETE — самый простой по смыслу: удалить указанный ресурс.
Пример: вы нажали «Удалить товар из корзины». Браузер отправляет DELETE-запрос с идентификатором товара. Сервер удаляет запись из базы.
Но на практике DELETE тоже не всегда идемпотентен. Повторный DELETE того же ресурса может вернуть 404 (не найдено) вместо 200 (успешно удалён). Спецификация допускает оба варианта, но важно, чтобы поведение было согласованным и не приводило к ошибкам.
Тестировщик проверяет: удаляется ли ресурс физически или просто помечается как удалённый? Что происходит с зависимыми данными? Что, если удалить родительский объект — удалятся ли дочерние?
Нюанс, который стоит запомнить: почему многие сайты используют POST вместо PUT и DELETE
В классических HTML-формах есть только два метода: GET и POST. PUT и DELETE не поддерживаются. Поэтому на веб-сайтах часто используют POST для всех изменяющих действий — и для создания, и для обновления, и для удаления.
Это не неправильно. Это компромисс.
Разработчики просто добавляют в POST-запрос скрытое поле, например _method=PUT, и на сервере маршрутизируют вызов в нужный обработчик. Или используют POST для всех операций, а тип действия определяют по URL.
Для тестировщика это важно, потому что вы можете встретить API, где PUT и DELETE вообще не используются. Это не баг, а архитектурное решение. Но оно влияет на ваши проверки: вместо отдельного DELETE вам придётся проверять удаление через POST с определённым параметром.
Главное — запомнить, что методы — это всего лишь соглашение. Важно, что реально делает сервер, а не как называется метод в запросе. Но если вы видите GET, который удаляет данные — это уже красный флаг.
Пример из практики
Допустим, вы тестируете интернет-магазин.
- GET /catalog — получить список товаров. Без параметров — все, с параметром category — отфильтрованные. Проверяете, что при каждом таком запросе количество товаров в базе не меняется.
- POST /order — создать новый заказ. Передаёте список товаров, адрес, способ оплаты. Проверяете, что заказ появляется в базе, что возвращается номер заказа и что при повторной отправке (без блокировки кнопки) не создаются дубли.
- PUT /user/123 — обновить профиль пользователя 123. Передаёте полный объект: имя, почту, телефон. Проверяете, что поля, которые вы не передали, действительно сбросились в пустоту или в дефолтные значения (если так задумано). Если разработчик обещал частичное обновление — значит, он использует не PUT, а PATCH.
- DELETE /cart/5 — удалить позицию корзины с ID 5. Проверяете, что после запроса эта позиция исчезает из корзины, и что при повторном DELETE возвращается 404 или корректный ответ.
Где обычно ошибаются новички
Ошибка первая: путают GET и POST. Начинают передавать чувствительные данные в GET — они попадают в адресную строку, логи браузера и историю. Так делать нельзя.
Ошибка вторая: думают, что POST никогда не кэшируется. Это не совсем так — при определённых настройках POST может кэшироваться, хотя обычно браузеры не кэшируют POST-ответы.
Ошибка третья: считают, что PUT удаляет все поля, которые вы не указали, — это обычно так, но не всегда. Некоторые реализации делают частичное обновление через PUT, хотя по спецификации это неверно. Уточняйте в документации.
Ошибка четвёртая: не проверяют идемпотентность DELETE. Повторное удаление может падать с ошибкой, если разработчик не обработал отсутствие ресурса. Это допустимо, но нужно проверить, что ошибка логичная, а не 500.
Практическое задание
Условие: откройте любой сайт с активным функционалом — например, интернет-магазин, соцсеть или даже этот Дзен. Зайдите в инструменты разработчика (DevTools) во вкладку Network, включите запись сетевой активности.
Что нужно сделать:
Найдите как минимум три запроса с разными методами (GET, POST, PUT или DELETE). Если PUT/DELETE не встречаются, найдите POST с разными URL — они могут выполнять разные действия.
Выпишите для каждого запроса:
- метод (GET, POST, PUT, DELETE)
- URL
- статус ответа (200, 404, 500 и т.п.)
- что вы делали на сайте, чтобы вызвать этот запрос.
Как оформить результат:
Пример ответа в комментариях:
- Метод: GET, URL: /catalog, статус: 200, действие: открыл главную страницу каталога.
- Метод: POST, URL: /api/order, статус: 201, действие: оформил заказ.
- Метод: DELETE, URL: /api/cart/5, статус: 204, действие: удалил товар из корзины.
Как проверить себя:
Вы нашли хотя бы один GET и один POST.
Вы указали статус ответа (если не знаете — цифры из столбца Status).
Вы описали действие своими словами, а не просто скопировали URL.
Если PUT/DELETE не нашли — честно напишите, что только POST, и объясните, почему так могло быть (это и есть тот самый компромисс HTML-форм).
Если застряли: на многих сайтах PUT и DELETE могут отсутствовать. Тогда найдите два разных POST-запроса — один для создания (например, регистрация), другой для изменения (например, обновление профиля). Сравните их URL и параметры.
Внимание. Это всего лишь 1 пост из многих, где я рассказываю теорию и даю практику для начинающих тестировщиков ПО. Если вы хотите вместе со мной пройти всю теорию, минимально подготовиться ко входу в эту профессию, приглашаю подписаться на мой Канал в Дзен:
Комментарии
Отправить комментарий