Какие HTTP-методы используются в REST API и для каких операций?

Тип вопроса: API тестирование Вероятность: 37% Категория: AQA / Automation

Ответ

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

Основные методы и их REST-семантика:

  1. GET (/users, /users/{id})

    • Назначение: Получение данных. Не должен изменять состояние сервера.
    • Пример: GET /users — получить список пользователей. GET /users/42 — получить пользователя с ID 42.

  2. POST (/users)

    • Назначение: Создание нового ресурса в коллекции. Идентификатор обычно генерируется сервером.
    • Пример: POST /users с телом {"name": "Alice"} — создать нового пользователя.

  3. PUT (/users/{id})

    • Назначение: Полное обновление существующего ресурса по известному URI. Требует отправки полного представления ресурса.
    • Пример: PUT /users/42 с телом {"id": 42, "name": "Alice Cooper"} — обновить все данные пользователя 42.

  4. PATCH (/users/{id})

    • Назначение: Частичное обновление ресурса. Отправляются только изменяемые поля (часто в формате JSON Patch).
    • Пример: PATCH /users/42 с телом {"op": "replace", "path": "/name", "value": "Alice"}.

  5. DELETE (/users/{id})

    • Назначение: Удаление ресурса.
    • Пример: DELETE /users/42 — удалить пользователя с ID 42.

Вспомогательные методы:

  • HEAD и OPTIONS используются для получения метаинформации (заголовки, CORS).

Ключевые принципы при тестировании:

  • Проверяйте соответствие кодов состояния (200 OK для успешного GET, 201 Created для POST, 204 No Content для успешного DELETE/PUT).
  • Учитывайте идемпотентность (повторение GET, PUT, DELETE не должно вызывать побочных эффектов, в отличие от POST).
  • Для PATCH-запросов важно тестировать корректность применения частичных изменений.

Ответ 18+ 🔞

Да ты посмотри на них, на этих REST-архитекторов! Сидят, блядь, выдумывают, как бы нам жизнь программистам усложнить, чтоб мы не расслаблялись, суки. Ну ладно, слушай сюда, разберём эту ихнюю «семантику», пока я не обосрался со смеху от этой бюрократии.

Вот представь: у тебя есть ресурс, ну, скажем, пользователи. Как шкаф, блядь, с бумажками. И есть у нас волшебные HTTP-глаголы — это как команды этому шкафу. И главный принцип, ёпта, чтобы всё было предсказуемо. Нельзя, блядь, командой «посмотреть» бумажку — её сжечь. Это пиздец.

Основные методы, или «Что почём»:

  1. GET (/users, /users/{id})

    • Назначение: Посмотреть, почитать, потрогать глазами. Ничего не должно поменяться на сервере, ни одной записи в логах, кроме факта того, что ты смотрел, хитрожопый.
    • Пример: GET /users — вынь да положь весь список. GET /users/42 — дай мне конкретно этого, Василия из бухгалтерии.

  2. POST (/users)

    • Назначение: Создать новую сущность, блядь. Ты приносишь на сервер свёрток с данными и говоришь: «Вот, заведи нового человека». Сервер сам придумывает ему ID и паспорт.
    • Пример: POST /users с телом {"name": "Alice"} — роди, блядь, Алису. И чтоб кричала.

  3. PUT (/users/{id})

    • Назначение: Полностью переписать, ёбта! Не «исправить запятую», а взять и заменить всю сущность целиком. Как будто старую бумажку в шреддер, а новую напечатал.
    • Пример: PUT /users/42 с телом {"id": 42, "name": "Alice Cooper"} — всё, твой Вася из бухгалтерии теперь Элис Купер, рок-звезда. Старых данных нет.

  4. PATCH (/users/{id})

    • Назначение: А вот это уже хитрая жопа. Частичное обновление. Типа «Вася, смени только фамилию, а должность и зарплату оставь». Часто используют JSON Patch, это когда ты отправляешь инструкцию, а не просто данные.
    • Пример: PATCH /users/42 с телом {"op": "replace", "path": "/name", "value": "Alice"}. Смотри, не перепутай path с тропинкой в лес, а то пиздец будет.

  5. DELETE (/users/{id})

    • Назначение: Удалить нахуй. Всё. Точка. В идеале — безвозвратно.
    • Пример: DELETE /users/42 — Вася, прощай. И даже не думай восстанавливаться из корзины.

А ещё есть вспомогательные, про которые все забывают, пока не припрет:

  • HEAD — «Дай мне только заголовки, тело нахуй не надо». Экономия трафика, мать его.
  • OPTIONS — «Эй, сервак, а что ты вообще умеешь с этим URL?». Часто для CORS-предзапросов, этих долбаных.

На что орать при тестировании, или «Где собака зарылась»:

  • Коды состояния — это святое! 200 OK — посмотрел, 201 Created — создал, 204 No Content — удалил или обновил, и тебе даже «ок» говорить лень. Если POST вернул 200, а не 201 — уже подозрение ебать чувствую.
  • Идемпотентность — выучи, блядь, это слово. GET, PUT, DELETE — сколько раз ни дергай, результат должен быть как от одного раза. А POST — не идемпотентный! Каждый новый POST — новый ресурс. Запомни, а то накосячишь.
  • PATCH — отдельный ад. Тестируй, что частичные изменения применяются точно, а не так, что вместо смены имени пользователь становится администратором. Это, блядь, частый сюрприз.

Вот и вся философия. Кажется просто, а потом смотришь на чужой API и понимаешь — автор прочитал это всё, обосрался и сделал наоборот. Ёперный театр.

© ХакСобесов, 2026
support@hacksobesov.com