¿Por qué el método PATCH no es idempotente?

Me preguntaba acerca de esto.

Supongamos que tengo un userrecurso con idy namecampos. Si quiero actualizar un campo, podría hacer una solicitud PATCH al recurso como este

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

Y luego la aplicación actualizará el nombre del usuario 42.

Pero, ¿por qué si repito esta solicitud, el resultado sería diferente?

De acuerdo con RFC 5789

PATCH no es seguro ni idempotente

Una solicitud de PARCHE puede ser idempotente, pero no es obligatorio que lo sea. Esa es la razón por la que se caracteriza como no idempotente.

Si PATCH puede ser idempotente o no, depende en gran medida de cómo se comunican los cambios requeridos.
Por ejemplo, si el formato del parche tiene la forma de {change: 'Name' from: 'benjamin franklin' to: 'john doe'}, entonces cualquier solicitud de PATCH después de la primera tendría un efecto diferente (una respuesta de falla) que la primera solicitud.
Otra razón para la no idempotencia puede ser que la aplicación de la modificación en algo más que el recurso original puede invalidar el recurso. Este también sería el caso si aplica el cambio varias veces.

Creo que la respuesta clara cuando PATCH no es idempotente es este párrafo de RFC 5789:

También hay casos en los que los formatos de parche no necesitan operar desde un punto base conocido (por ejemplo, agregar líneas de texto a archivos de registro o filas no colisionantes a las tablas de la base de datos), en cuyo caso no se necesita el mismo cuidado en las solicitudes del cliente .

Como RFC especifica que el parche contiene algunos "cambios generales" en el recurso, deberíamos mirar más allá del reemplazo de campo típico. Si el recurso es para un contador, entonces el parche puede solicitar su incremento, lo que claramente no es idempotet.

PATCHlas solicitudes describen un conjunto de operaciones que se aplicarán a un recurso; si aplica el mismo conjunto de operaciones dos veces al mismo recurso, el resultado puede no ser el mismo. Esto se debe a que definir las operaciones depende de usted. En otras palabras, debe definir las reglas de fusión .

Recuerde que una PATCHsolicitud podría usarse para parchear recursos en muchos formatos diferentes, no solo JSON.

Por lo tanto, una PATCHsolicitud puede ser idempotente si define las reglas de fusión como idempotentes .

Ejemplo idempotente:

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

// PATCH request
{
  age: 33
}

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

Ejemplo no idempotente:

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

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

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

En el segundo ejemplo utilicé una sintaxis "Mongo like" que inventé para incrementar un atributo. Claramente, esto no es idempotente, ya que enviar la misma solicitud varias veces daría como resultado resultados diferentes cada vez.

Ahora puede que se pregunte si el uso de una sintaxis inventada es válida. Según las normas , es:

La diferencia entre las solicitudes PUT y PATCH se refleja en la forma en que el servidor procesa la entidad adjunta para modificar el recurso identificado por el URI de solicitud. En una solicitud PUT, la entidad adjunta se considera una versión modificada del recurso almacenado en el servidor de origen, y el cliente solicita que se reemplace la versión almacenada. Sin embargo, con PATCH, la entidad adjunta contiene un conjunto de instrucciones que describen cómo se debe modificar un recurso que actualmente reside en el servidor de origen para producir una nueva versión.

Y es posible que también se pregunte si es tranquilo usar las PATCHsolicitudes de esta manera, y muchas personas consideran que no, aquí hay una buena respuesta con muchos comentarios sobre el tema.