Что такое HTTP-метод PATCH?

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

Представь, у тебя пользователь в базе, целая хуета полей: имя, почта, возраст, аватарка, подписка на спам. И ему надо только почту сменить, потому что он, мудак, её потерял. Ну зачем тебе, как дураку, гонять на сервер всю его биографию, включая размер обуви? Ни к чему! Берёшь PATCH и шлёшь только новую почту. Всё, пипец, обновилось.

Вот, смотри, как это выглядит, если по-простому:

PATCH /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "email": "updated@example.com",
  "age": 30
}

Видишь? Никакого лишнего дерьма. Сказали: «Эй, сервак, у юзера 123 поменяй почту и возраст». Остальное — не трогай, там и так всё в ажуре.

Но тут, конечно, есть свои подводные ебеня, о которых надо помнить, а то наебнёшься.

Во-первых, про идемпотентность. Ну, PUT — он и в Африке идемпотентный: отправил десять раз одно и то же — ресурс как был обновлён, так и остался. А PATCH — он, сука, такой раздолбай. Теоретически, если ты десять раз шлёшь «увеличить счётчик на 1», то он десять раз и увеличит, и будет овердохуища. Поэтому, если можешь — делай операции так, чтобы от повторения нихуя не менялось. Это как лучшая практика, блядь.

Во-вторых, и это самое главное — договориться, КАК именно ты описываешь изменения. А то придёт к тебе клиент, начнёт слать какую-то свою хуйню, а ты её не поймёшь. Есть два основных способа, как умные дядьки договорились:

1. JSON Merge Patch. Это просто JSON, где ты пишешь новые значения. Если хочешь поле удалить — пишешь в нём null. Проще пареной репы, но есть нюансы, блядь. С вложенными массивами, например, не поиграешь.
2. JSON Patch (RFC 6902). Вот это уже серьёзная тема, для перфекционистов. Там целый язык операций: add, remove, replace, move, copy. Хочешь — поле добавь, хочешь — удали, хочешь — пятый элемент массива замени. Мощно, но и писать его — тот ещё геморрой. Выбирай, что для твоего проекта больше подходит, и пиши в документации, блядь, крупными буквами: «ШЛИ ТАК, А НЕ ИНАЧЕ, А ТО В ЖОПУ ПОЛУЧИШЬ».

В-третьих, безопасность, ёпта! Нельзя просто так взять и разрешить через PATCH менять что попало. Например, поле isAdmin с false на true. Или balance с 0 на 1000000. Сервер должен эту хуйню валидировать, как сторожевой пёс. Принял запрос, проверил, что клиент имеет право менять именно эти поля, и что новые значения не превратят твою базу в помойку. И только потом применяй.

А зачем вообще этот PATCH нужен? Да затем, чувак, чтобы не гонять по сети гигабайты ерунды! Особенно когда ресурс большой, как описание космического корабля. Меняешь ты там только название двигателя, а зачем-то должен отправить всю схему электропроводки. Бред же, да? PATCH решает эту проблему на раз-два.

Короче, инструмент охуенный, но острый. Пользуйся с умом, не выёбывайся, и всё будет в шоколаде.