Почему нужно использовать PATCH, а не POST для обновления ресурсов в REST API

Использование PATCH вместо POST для обновлений следует принципам семантики HTTP и идемпотентности REST API.

Ключевые различия:

Практический пример из моего опыта с JSON API:

// POST — для создания (не для обновления!)
POST /api/users
{
  "name": "Alice",
  "email": "alice@example.com",
  "role": "user"
}
// → Создаёт нового пользователя, возвращает 201 Created

// PATCH — для частичного обновления
PATCH /api/users/123
{
  "email": "new.alice@example.com"
}
// → Обновляет только email, возвращает 200 OK

// PUT — для полной замены (редко используется)
PUT /api/users/123
{
  "name": "Alice",
  "email": "new.alice@example.com",
  "role": "user"
}
// → Заменяет ВСЕ поля, null для отсутствующих

Преимущества PATCH:

1. Эффективность сети — передаются только изменяемые данные
2. Безопасность — нельзя случайно затереть другие поля
3. Поддержка конкурентности — можно использовать с ETag или If-Match
4. Чёткая семантика — сразу понятно, что происходит частичное обновление

Реализация в Laravel:

// В контроллере
public function update(UserUpdateRequest $request, User $user)
{
    // PATCH-запрос автоматически обрабатывается
    $user->update($request->validated());
    return response()->json($user);
}

В микросервисной архитектуре мы строго соблюдали это различие, что упрощало интеграцию между сервисами.