Ответ
PUT и PATCH — это HTTP-методы для обновления ресурсов, но с разной семантикой.
PUT— полная замена ресурса. Клиент должен отправить полное представление ресурса. Отсутствующие в запросе поля будут удалены или сброшены в значения по умолчанию.PATCH— частичное обновление ресурса. Клиент отправляет только те поля, которые необходимо изменить.
Практический пример (Обновление пользователя):
Исходный ресурс GET /users/123:
{
"id": 123,
"name": "John",
"email": "john@old.com",
"age": 25
}Запрос PUT:
PUT /users/123
Content-Type: application/json
{
"name": "John Doe",
"age": 26
}Результат (GET /users/123): Поле email удалено, так как не было передано.
{
"id": 123,
"name": "John Doe",
"age": 26
}Запрос PATCH:
PATCH /users/123
Content-Type: application/json
{
"age": 26
}Результат (GET /users/123): Изменилось только поле age, email остался нетронутым.
{
"id": 123,
"name": "John",
"email": "john@old.com",
"age": 26
}Важные свойства:
- Идемпотентность:
PUT— идемпотентен (многократный вызов с одними данными дает тот же результат).PATCH— не обязательно идемпотентен (зависит от реализации сервера). - Использование:
PUTподходит для создания/полной перезаписи ресурса, когда клиент управляет всем его состоянием.PATCHэффективен для точечных обновлений, особенно для больших ресурсов, уменьшая трафик и предотвращая конфликты.
Ответ 18+ 🔞
А, слушай, смотри, вот эти ваши PUT и PATCH — они вроде оба для обновления, но разница там, блядь, как между «переехать в новую квартиру» и «починить унитаз». Охуеть, да?
PUT— это, сука, полная замена, тотальная. Ты приносишь на сервер весь новый ресурс, целиком. Что не принёс — того нахуй и не будет, сгорит в аду. Сервер смотрит: «А, понятно, старую версию — на свалку, кладём вот эту». Если забыл про полеemail— пиши пропало, пользователь теперь без мыла, как бомж.PATCH— это точечный ремонт, хирургический. «Доктор, у меня тут только возраст болит, на 26 поменяйте, а всё остальное не трогайте, оно норм». Идеально.
Смотри, как это на практике, на примере какого-нибудь юзера:
Допустим, был у нас чувак. Запросили его: GET /users/123
{
"id": 123,
"name": "John",
"email": "john@old.com",
"age": 25
}Ситуация первая: прилетает PUT, как танк.
PUT /users/123
Content-Type: application/json
{
"name": "John Doe",
"age": 26
}И что получается? А получается, что сервер, такой: «О, новый Джон! Вижу только имя и возраст. Значит, это и есть весь Джон. Старого — в мусорку!». И отныне наш юзер выглядит так:
{
"id": 123,
"name": "John Doe",
"age": 26
}Почта john@old.com? Да хуй там! Её в запросе не было — значит, её в природе не существует. Джон теперь без email, ебать его в сраку. Полная замена, мать её.
Ситуация вторая: прилетает PATCH, как снайпер.
PATCH /users/123
Content-Type: application/json
{
"age": 26
}И сервер, такой довольный: «Ага! Значит, нужно только возраст поменять на 26. Остальное — не трогаем, работает же». Итог:
{
"id": 123,
"name": "John",
"email": "john@old.com",
"age": 26
}Всё на месте, только возраст подправили. Красота!
А теперь, блядь, важные нюансы, чтобы не обосраться:
- Идемпотентность (это когда сколько раз ни делай — результат один):
PUT— идемпотентный, да. Десять раз шлёшь одно и то же — ресурс после первого раза уже такой и останется. А вотPATCH— тут как повезёт. Если он просто значения меняет, то может быть идемпотентным. А если он, например, «увеличить счётчик на 1» — то каждый вызов будет плюсовать, тут уже пиши пропало, идемпотентности ноль ебать. - Когда что юзать:
PUT— когда ты бог и знаешь всё состояние ресурса. Или для полной перезаписи/создания.PATCH— это овердохуища удобно, когда ресурс большой, а поменять надо три поля. Трафик меньше, конфликтов при параллельном редактировании тоже меньше. В общем, умный выбор.