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

Question

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

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

Ответ

Для изменения данных в REST API используются методы PUT и PATCH. Их ключевое отличие — в объеме изменяемых данных.

PUT

Полная замена ресурса. Клиент должен отправить полное представление ресурса.
Если передать неполные данные, отсутствующие поля могут быть сброшены в null или значения по умолчанию.
Идемпотентен: многократный вызов с одними данными дает тот же результат, что и однократный.

PUT /api/users/123 HTTP/1.1
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com",
  "age": 30
}

PATCH

Частичное обновление ресурса. Клиент отправляет только изменяемые поля.
Остальные поля ресурса остаются нетронутыми.
Не всегда идемпотентен, зависит от реализации.

PATCH /api/users/123 HTTP/1.1
Content-Type: application/json

{
  "age": 31
}

Выбор метода:

Используйте PUT, когда клиент управляет всем состоянием ресурса (например, редактирование профиля через форму).
Используйте PATCH для оптимизации трафика и обновления отдельных полей (например, смена статуса или настройки).

⚠️ Важно: Точная семантика методов может зависеть от реализации сервера. Всегда сверяйтесь с документацией конкретного API.

Ответ 18+ 🔞

А, слушай, вот тут у нас, блядь, два метода, которые данные меняют — PUT и PATCH. Разница между ними, сука, как между полной заменой двигателя и просто масло поменять. Сейчас разжуём.

PUT — это пиздец какой серьёзный

Полная замена, блядь. Ты должен отправить на сервер ВСЁ, что у этого ресурса есть. Весь объект, целиком, сука.
Если ты, мудак, отправишь только имя и возраст, а про почту забудешь — сервер может подумать: "А, ну значит почты теперь нет, нахуй". И сбросит её в null. Пиздец, да?
Идемпотентный он, ёпта. Это умное слово значит, что сколько раз ни дерни — хуй с горы, результат один и тот же. Отправил десять раз одни и те же данные — ресурс после первого раза уже не изменится.

PUT /api/users/123 HTTP/1.1
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com",
  "age": 30
}

Вот тут, понимаешь, ты говоришь: "Забудь всё, что было про юзера 123. Теперь он вот этот чувак, целиком. В рот меня чих-пых!"

PATCH — хитрая жопа

Частичное обновление, блядь. Ты шлёшь только то, что хочешь поменять. Всё остальное — на своём месте, не тронуто.
С идемпотентностью тут, блядь, как повезёт. Зависит от того, как серверную логику писали. Если там "увеличить счётчик на 1", то каждый вызов будет результат менять — это уже не идемпотентно, пиздец.

PATCH /api/users/123 HTTP/1.1
Content-Type: application/json

{
  "age": 31
}

А тут ты такой: "Всё у юзера 123 оставь как есть, блядь, только возраст ему на годик подкрути. День рождения, сука, был".

Так когда что юзать, бля?

PUT — когда ты, блядь, полностью контролируешь состояние. Ну, типа, форма редактирования профиля открылась — ты там всё поменял и жмёшь "Сохранить". Отправляется ВСЯ новая хуйня.
PATCH — когда оптимизация, ёпта. Нехуй гонять по сети весь объект в 100500 полей, чтобы поменять одну галочку "подписка на рассылку". Послал только эту галочку — и все дела, мудя.

⚠️ Внимание, ебать мои старые костыли! Как сервер это всё обрабатывает — на его совести. Один может по PUT недостающие поля игнорить, а другой — занулять. Поэтому, чувак, читай документацию к конкретному API, а не тыкай методы наобум, а потом удивляешься, куда данные делись.