Как ответить
Основное различие между PUT и PATCH в том, что PUT заменяет ресурс целиком, а PATCH — изменяет только указанные поля. PUT идемпотентен: повторный запрос с теми же данными даст тот же результат. PATCH не обязан быть идемпотентным — один и тот же запрос, применённый несколько раз, может привести к разным состояниям (например, увеличение счётчика на 1).
Рассмотрим на примере: у нас есть пользователь с полями name, email, age.
PUT — передаём полный объект:
PUT /users/123
Content-Type: application/json
{
"name": "Иван Петров",
"email": "ivan@example.com",
"age": 30
}Если не передать поле age, сервер обычно установит его в null или значение по умолчанию — ресурс перезаписывается целиком.
PATCH — передаём только то, что нужно изменить. Самый простой способ — передать частичный JSON (JSON Merge Patch, RFC 7396):
PATCH /users/123
Content-Type: application/merge-patch+json
{
"email": "newemail@example.com"
}В этом случае остальные поля (name, age) остаются без изменений.
Другой формат — JSON Patch (RFC 6902), где операции описываются явно:
PATCH /users/123
Content-Type: application/json-patch+json
[
{ "op": "replace", "path": "/email", "value": "newemail@example.com" }
]Этот формат точнее описывает действия (добавить, удалить, заменить).
Практические советы для junior:
- Если клиент отправляет весь ресурс — используйте PUT. Даже если изменили только одно поле, но передали всё — PUT.
- Если нужно изменить одно-два поля и не хотите рисковать, что незаданные поля сбросятся — используйте PATCH.
- Учитывайте, что не все серверы правильно обрабатывают PATCH — иногда за ним скрывается полная замена. Всегда читайте документацию API.
- Идемпотентность PUT позволяет безопасно повторять запросы при сетевых ошибках. PATCH без идемпотентности может вызвать дублирование действий; для критических операций лучше сделать PUT или обеспечить идемпотентность на уровне логики.
В REST-дизайне это различие важно: PUT для обновления всего ресурса (или создания с известным ID), PATCH — для частичного изменения.