Ответ
Для обновления ресурсов в REST API используются два основных HTTP-метода: PUT и PATCH. Они служат разным целям и имеют ключевые семантические различия.
PUT
Метод PUT используется для полной замены ресурса по указанному URI. Клиент должен передать в теле запроса полную репрезентацию ресурса. Если какие-то поля не будут переданы, сервер может интерпретировать это как их удаление или установку в значение по умолчанию.
Ключевая характеристика — идемпотентность. Это означает, что многократное выполнение одного и того же PUT запроса будет иметь тот же эффект, что и однократное.
Пример:
Предположим, ресурс /users/123 выглядит так: {"username": "alex", "status": "active"}.
Запрос на полную замену:
PUT /users/123
Content-Type: application/json
{
"username": "alex_new",
"status": "inactive"
}Ресурс будет полностью заменен. Если бы мы отправили только {"username": "alex_new"}, поле status было бы удалено или сброшено.
PATCH
Метод PATCH используется для частичного обновления ресурса. В теле запроса передаются только те поля, которые необходимо изменить. Остальные поля остаются нетронутыми.
Ключевая характеристика — не является идемпотентным по своей природе (хотя конкретная реализация может быть идемпотентной).
Пример:
Для того же ресурса /users/123 обновим только статус:
PATCH /users/123
Content-Type: application/json
{
"status": "archived"
}Поле username останется без изменений, изменится только status.
Когда что использовать?
PUT: Когда вы хотите полностью заменить существующий ресурс. Удобно для форм редактирования, где пользователь видит и может изменить все поля объекта.PATCH: Когда нужно изменить одно или несколько полей, не затрагивая остальные. Идеально подходит для атомарных изменений, например, смены статуса задачи или обновления имени пользователя.
Ответ 18+ 🔞
Давай разберём эту дичь, про которую все так умно говорят, а на деле всё просто, как три копейки. Речь про то, как обновлять данные в твоём API, чтобы не накосячить.
Представь, у тебя есть пользователь в базе. Вот он, красавец:
{
"username": "alex",
"status": "active"
}Теперь, смотри, есть два главных способа его поменять: PUT и PATCH. И разница между ними — просто пиздец какая важная, а то потом будешь чесать репу, почему всё сломалось.
Метод PUT — это как переезд на новую квартиру
Ты берёшь и полностью заменяешь всё, что было. Всё, блядь, до последнего гвоздя. Отправляешь новый полный набор данных. Если чего-то в этом наборе нет — сервер подумает: «А, ну значит, этого поля больше не должно быть», и удалит его нахуй. Или в дефолт сбросит.
Главная фишка PUT — он идемпотентный. Это умное слово значит, что если ты десять раз подряд шлёшь один и тот же запрос, результат будет такой же, как если бы ты послал его один раз. Не создаётся хуйни лишней.
Пример: Хочешь поменять и имя, и статус? Шли полный пакет!
PUT /users/123
Content-Type: application/json
{
"username": "alex_new",
"status": "inactive"
}После этого у пользователя будет ТОЛЬКО то, что ты отправил. Если бы отправил только {"username": "alex_new"}, то поле status могло бы просто испариться в небытие. Вот такая, блядь, тотальная замена.
Метод PATCH — это как точечный ремонт
А вот это уже то, что надо! Не хочешь трогать весь объект? Хочешь поменять только одно поле, например, статус? Используй PATCH. Ты шлёшь только те изменения, которые нужны. Всё остальное остаётся как было, живёт своей жизнью.
Он по умолчанию не идемпотентный. Хотя, если очень постараться, можно сделать и так, но это уже твои заморочки.
Пример: Нужно только заархивировать пользователя? Легко!
PATCH /users/123
Content-Type: application/json
{
"status": "archived"
}И всё! Имя username останется «alex», а статус поменяется. Красота, ёпта!
Так когда что юзать, чтобы не облажаться?
PUT— когда у тебя есть форма редактирования, где пользователь видит ВСЕ поля объекта и может их все поменять. Полная замена, чётко и ясно.PATCH— когда нужно сделать маленькое, точечное изменение. Смена статуса задачи, обновление аватара, подписка на рассылку — вот это всё. Экономия трафика и нервов, блядь.
Короче, запомни: PUT — всё сносим и строим заново, PATCH — подкрашиваем только ту стенку, которая облезла. Выбирай с умом, а то потом будешь искать, куда делось поле status, а оно, оказывается, нахуй улетело из-за кривого PUT-запроса.