Перейти на PRO

С какими HTTP-методами (веб-запросами) вы работали при тестировании API?

Тип вопроса: API тестирование Вероятность: 10% Категория: QA Тестировщик

Ответ

При тестировании API активно работал со стандартными HTTP-методами (глаголами), каждый из которых определяет тип операции над ресурсом.

Основные HTTP-методы и их назначение:

Метод Идиоматическое назначение (REST) Пример использования
GET Получение данных. Без побочных эффектов (идемпотентный, безопасный). Получить список пользователей или конкретного пользователя.
POST Создание нового ресурса. Создать нового пользователя, отправить данные формы.
PUT Полное обновление ресурса. Создает ресурс, если он не существует (идемпотентный). Обновить все поля профиля пользователя.
PATCH Частичное обновление ресурса. Обновить только email пользователя.
DELETE Удаление ресурса (идемпотентный). Удалить пользователя по ID.

Практические примеры запросов (cURL):

# 1. GET: Получение пользователя с ID 123
curl -X GET "https://api.example.com/v1/users/123" 
     -H "Authorization: Bearer <token>"

# 2. POST: Создание нового пользователя с JSON-телом
curl -X POST "https://api.example.com/v1/users" 
     -H "Content-Type: application/json" 
     -H "Authorization: Bearer <token>" 
     -d '{"name": "Alice", "email": "alice@example.com"}'

# 3. PUT: Полное обновление пользователя с ID 123
curl -X PUT "https://api.example.com/v1/users/123" 
     -H "Content-Type: application/json" 
     -d '{"name": "Alice Smith", "email": "alice.smith@example.com"}'

# 4. DELETE: Удаление пользователя с ID 123
curl -X DELETE "https://api.example.com/v1/users/123" 
     -H "Authorization: Bearer <token>"

Что проверял в запросах и ответах:

  • Коды состояния HTTP (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error).
  • Заголовки (Headers): Content-Type, Authorization, Accept.
  • Тело запроса (Body): Форматы JSON, XML, x-www-form-urlencoded.
  • Параметры: Query-параметры, path-переменные.
  • Структура и валидация данных в ответе (соответствие контракту/схеме).

Ответ 18+ 🔞

Да ты посмотри, на что я время тратил! Сидел, блядь, как дурак, и тыкал в эти ваши API, пока не понял, что вся суть — в этих ёбаных HTTP-глаголах. Это ж как букварь, только для интернета!

Вот смотри, таблица, чтоб ты не ебал мозги:

Метод Что делает, если по-простому Где тыкать
GET Достать что-то. Просто посмотреть, не трогая. Безопасно, как стекло в музее. Получить список юзеров или одного конкретного.
POST Создать что-то новое. Воткнул данные — получил новый ресурс. Создать нового юзера, отправить форму.
PUT Полностью переписать что-то старое. "Забудь всё, что было, вот тебе новая правда". Если нет — создаст. Обновить ВЕСЬ профиль юзера.
PATCH Подправить чутка. Не трогай лишнее, поменяй только то, что сказали. Сменить только email у юзера.
DELETE Удалить нахуй. Что тут объяснять? Послал запрос — ресурса нет. Удалить юзера по айдишнику.

А вот как это выглядит в деле, в этой консольной магии под названием cURL:

# 1. GET: Посмотреть на юзера с ID 123
curl -X GET "https://api.example.com/v1/users/123" 
     -H "Authorization: Bearer <token>"

# 2. POST: Создать нового юзера (Алису, мать её)
curl -X POST "https://api.example.com/v1/users" 
     -H "Content-Type: application/json" 
     -H "Authorization: Bearer <token>" 
     -d '{"name": "Alice", "email": "alice@example.com"}'

# 3. PUT: Переписать юзера 123 целиком
curl -X PUT "https://api.example.com/v1/users/123" 
     -H "Content-Type: application/json" 
     -d '{"name": "Alice Smith", "email": "alice.smith@example.com"}'

# 4. DELETE: Отправить юзера 123 в цифровое небытие
curl -X DELETE "https://api.example.com/v1/users/123" 
     -H "Authorization: Bearer <token>"

И на что я, как конченый перфекционист, смотрел, когда тестил эту хуйню:

  • Коды ответа (Status Codes): Это ж святое! 200 — ок, 201 — создано, 400 — ты мудак и отправил хуйню, 401 — тебе сюда нельзя, 404 — нихуя нет, 500 — у них там всё сломалось, сиди жди.
  • Заголовки (Headers): Content-Type — в каком формате данные, Authorization — твой пропуск, Accept — что ты хочешь получить в ответ.
  • Тело запроса (Body): JSON, XML или эти старые добрые x-www-form-urlencoded. Главное — отправить то, что ждут, а не ахинею.
  • Параметры: Те, что в строке запроса (после ?) или прямо в пути URL.
  • Структура ответа: Чтобы всё было как в договоре (схеме), а не "ой, а мы тут поле username переименовали в user_name, извините".
© ХакСобесов, 2026
support@hacksobesov.com