Когда применяется PATCH?

Основное применение PATCH

PATCH — это метод HTTP, предназначенный для частичного обновления ресурса. В отличие от PUT, который предполагает полную замену ресурса, PATCH позволяет изменять только определенные поля, отправляя лишь разницу между текущим и желаемым состоянием. Это делает его идеальным для сценариев, где передача всего объекта избыточна или неэффективна.

Ключевые сценарии использования

• Экономия трафика и повышение производительности. Когда ресурс содержит множество полей (например, профиль пользователя с десятками свойств), а изменить нужно только одно (например, email), отправка полного объекта через PUT была бы расточительной. PATCH передает только изменяемые данные.
• Предотвращение конфликтов при параллельных изменениях. В системах, где несколько клиентов могут редактировать разные части одного ресурса одновременно, PATCH (особенно с применением стратегий вроде JSON Patch) минимизирует риск перезаписи изменений друг друга по сравнению с PUT.
• Атомарные операции. Спецификации, такие как JSON Patch (RFC 6902) и JSON Merge Patch (RFC 7386), позволяют описывать изменения как последовательность операций (add, remove, replace, move, copy). Это делает обновление более предсказуемым и мощным.
• Работа с большими или сложными структурами. Например, обновление одного элемента в большом массиве или изменение вложенного свойства глубоко внутри объекта.

Технические аспекты и примеры

Стандарт не строго определяет формат тела запроса PATCH, но на практике широко используются два формата:

1. JSON Merge Patch (RFC 7386)

Более простой формат. Чтобы изменить поле — передайте его с новым значением. Чтобы удалить поле — передайте его со значением null.

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

{
  "email": "new.email@example.com",
  "settings": {
    "theme": "dark"
  },
  "nickname": null // Удаление поля
}

Ограничение: Не поддерживает явные операции с массивами (например, изменение отдельного элемента по индексу).

2. JSON Patch (RFC 6902)

Более мощный и формальный формат. Тело запроса представляет собой массив операций.

PATCH /api/articles/456 HTTP/1.1
Content-Type: application/json-patch+json

[
  { "op": "replace", "path": "/title", "value": "Новый заголовок" },
  { "op": "add", "path": "/tags", "value": ["javascript"] },
  { "op": "remove", "path": "/draft" },
  { "op": "move", "from": "/oldLocation", "path": "/newLocation" }
]

Сравнение с PUT и POST

Идемпотентность — свойство, при котором многократное выполнение одной и той же операции приводит к одинаковому результату.

Практические рекомендации для Frontend-разработчика

1. Согласуйте формат с бэкендом. Важно четко договориться, какой тип PATCH (merge-patch или json-patch) и какие операции поддерживает ваш API.
2. Обработка ошибок. Поскольку PATCH может содержать несколько операций, необходим детальный отклик об ошибках (например, какие именно операции не прошли и почему). Используйте статус 422 Unprocessable Entity или 400 Bad Request с деталями в теле ответа.
3. Оптимистичные обновления в UI. PATCH идеально ложится в парадигму оптимистичного обновления интерфейса. Вы можете мгновенно отразить изменение на клиенте, а затем отправить компактный PATCH-запрос на сервер. В случае ошибки — откатить изменения.
4. Безопасность. Всегда валидируйте входящие операции на сервере. Клиент не должен иметь возможность изменить поля, которые ему не принадлежат (например, isAdmin), просто не указав их в схеме обновления.
5. Используйте правильные заголовки. Указывайте Content-Type: application/merge-patch+json или application/json-patch+json.

Заключение

PATCH — это специализированный инструмент для точной и эффективной модификации данных. Его применение особенно оправдано в современных SPA-приложениях, где频繁но происходят небольшие обновления состояния на сервере в ответ на действия пользователя. Правильное использование PATCH снижает нагрузку на сеть, уменьшает вероятность конфликтов и приводит к более чистой и декларативной архитектуре API.