Почему метод PATCH не идемпотентен?

Мне было интересно об этом.

Предположим , у меня есть userресурс с idи nameполей. Если я хочу обновить поле, я мог бы просто сделать запрос PATCH к ресурсу, как это

PATCH /users/42
{"name": "john doe"} 

И тогда приложение обновит имя пользователя 42.

Но почему, если я повторю этот запрос, результат будет другим?

Согласно RFC 5789

PATCH не является ни безопасным, ни идемпотентным

Запрос PATCH может быть идемпотентным, но это не обязательно. Вот почему он характеризуется как неидемпотентный.

Может ли PATCH быть идемпотентным или нет, сильно зависит от того, как сообщаются требуемые изменения.
Например, если формат патча имеет форму {change: 'Name' from: 'benjamin franklin' to: 'john doe'}, то любой запрос PATCH после первого будет иметь другой эффект (ответ об ошибке), чем первый запрос.
Другой причиной неидемпотентности может быть то, что применение модификации к чему-то другому, чем исходный ресурс, может сделать ресурс недействительным. Это также будет иметь место, если вы примените изменение несколько раз.

Я думаю, что четкий ответ, когда PATCH в не идемпотентном является этот абзац из RFC 5789:

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

Поскольку RFC указывает, что исправление содержит некоторые «общие изменения» ресурса, мы должны смотреть не только на типичную замену поля. Если ресурс предназначен для счетчика, то patch может запросить его приращение, что явно не идемпотет.

PATCHЗапросы описывают набор операций, которые будут применены к ресурсу. Если вы примените один и тот же набор операций дважды к одному и тому же ресурсу, результат может не совпадать. Это потому, что определение операций зависит от вас. Другими словами, вы должны определить правила объединения .

Помните, что PATCHзапрос может использоваться для исправления ресурсов во многих различных форматах, а не только в формате JSON.

Таким образом, PATCHзапрос может быть идемпотентным, если вы определяете правила слияния как идемпотентные .

Идемпотентный пример:

// Original resource
{
  name: 'Tito',
  age: 32
}

// PATCH request
{
  age: 33
}

// New resource
{
  name: 'Tito',
  age: 33
}

Неидемпотентный пример:

// Original resource
{
  name: 'Tito',
  age: 32
}

// PATCH request
{
  $increment: 'age'
}

// New resource
{
  name: 'Tito',
  age: 33
}

Во втором примере я использовал синтаксис типа «Монго», который я создал для увеличения атрибута. Понятно, что это не идемпотент, так как отправка одного и того же запроса несколько раз приведет к разным результатам каждый раз.

Теперь вы можете задаться вопросом, допустимо ли использование такого составного синтаксиса. Согласно стандартам это:

Разница между запросами PUT и PATCH отражается в способе, которым сервер обрабатывает вложенный объект для изменения ресурса, идентифицируемого Request-URI. В запросе PUT вложенный объект считается модифицированной версией ресурса, хранящегося на исходном сервере, и клиент запрашивает замену сохраненной версии. Однако с помощью PATCH вложенный объект содержит набор инструкций, описывающих, как ресурс, находящийся в данный момент на исходном сервере, должен быть модифицирован для создания новой версии.

И вы можете также задаться вопросом, насколько удобно использовать PATCHзапросы таким образом, и многие считают, что это не так, вот хороший ответ с большим количеством комментариев по данной проблеме.