Perché il metodo PATCH non è idempotente?

Mi chiedevo questo.

Supponiamo che io abbia una userrisorsa con ide namecampi. Se voglio aggiornare un campo potrei semplicemente fare una richiesta PATCH alla risorsa in questo modo

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

E quindi l'applicazione aggiornerà il nome dell'utente 42.

Ma perché se ripeto questa richiesta il risultato sarebbe diverso?

Secondo RFC 5789

PATCH non è né sicuro né idempotente

Una richiesta PATCH può essere idempotente, ma non è necessario che lo sia. Questo è il motivo per cui è caratterizzato come non idempotente.

Il fatto che PATCH possa essere idempotente o meno dipende fortemente dal modo in cui vengono comunicate le modifiche richieste.
Ad esempio, se il formato della patch è sotto forma di {change: 'Name' from: 'benjamin franklin' to: 'john doe'}, allora qualsiasi richiesta PATCH dopo la prima avrebbe un effetto diverso (una risposta di errore) rispetto alla prima richiesta.
Un altro motivo di non idempotenza può essere che l'applicazione della modifica su qualcos'altro rispetto alla risorsa originale può rendere la risorsa non valida. Questo sarebbe anche il caso se si applica la modifica più volte.

Penso che una risposta chiara quando PATCH in non idempotente sia questo paragrafo di RFC 5789:

Ci sono anche casi in cui i formati di patch non devono operare da un punto base noto (ad es. Aggiunta di righe di testo ai file di registro o righe non collidenti a tabelle di database), nel qual caso non è necessaria la stessa cura nelle richieste del client .

Poiché RFC specifica che la patch contiene alcune "modifiche generali" alla risorsa, dovremmo guardare oltre la tipica sostituzione del campo. Se la risorsa è per un contatore, la patch può richiederne l'incremento, che chiaramente non è idempotet.

PATCHle richieste descrivono un insieme di operazioni da applicare a una risorsa, se si applica lo stesso insieme di operazioni due volte alla stessa risorsa, il risultato potrebbe non essere lo stesso. Questo perché la definizione delle operazioni dipende da te. In altre parole, devi definire le regole di fusione .

Ricorda che una PATCHrichiesta potrebbe essere utilizzata per applicare patch alle risorse in molti formati diversi, non solo JSON.

Quindi una PATCHrichiesta può essere idempotente se si definiscono le regole di fusione come idempotenti .

Esempio idempotente:

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

// PATCH request
{
  age: 33
}

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

Esempio non idempotente:

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

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

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

Nel secondo esempio ho usato una sintassi "Mongo like" che ho inventato per incrementare un attributo. Chiaramente questo non è idempotente, poiché l'invio della stessa richiesta più volte comporterebbe risultati diversi ogni volta.

Ora ti starai chiedendo se l'uso di tale sintassi inventata è valido. Secondo gli standard , è:

La differenza tra le richieste PUT e PATCH si riflette nel modo in cui il server elabora l'entità inclusa per modificare la risorsa identificata dall'URI di richiesta. In una richiesta PUT, l'entità inclusa viene considerata una versione modificata della risorsa memorizzata sul server di origine e il client richiede la sostituzione della versione archiviata. Con PATCH, tuttavia, l'entità racchiusa contiene una serie di istruzioni che descrivono come modificare una risorsa attualmente residente sul server di origine per produrre una nuova versione.

E potresti anche chiederti se è riposante utilizzare le PATCHrichieste in questo modo, e molte persone ritengono che non lo siano, ecco una buona risposta con molti commenti sul problema.