Dlaczego metoda PATCH nie jest idempotentna?

Zastanawiałem się nad tym.

Załóżmy, że mam userzasób idi namepolami. Jeśli chcę zaktualizować pole, mogę po prostu wysłać PATCH do takiego zasobu

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

A następnie aplikacja zaktualizuje nazwę użytkownika 42.

Ale dlaczego, jeśli powtórzę tę prośbę, wynik byłby inny?

Zgodnie z RFC 5789

PATCH nie jest bezpieczny ani idempotentny

Żądanie PATCH może być idempotentne, ale nie jest to wymagane. Z tego powodu określa się go jako niestosowny.

To, czy PATCH może być idempotentny, zależy od tego, w jaki sposób przekazywane są wymagane zmiany.
Na przykład, jeśli format poprawki ma postać {change: 'Name' from: 'benjamin franklin' to: 'john doe'}, to każde żądanie PATCH po pierwszym będzie miało inny efekt (odpowiedź na błąd) niż pierwsze żądanie.
Innym powodem braku idempotencji może być to, że zastosowanie modyfikacji do czegoś innego niż oryginalny zasób może spowodować, że zasób będzie nieważny. Tak byłoby również w przypadku wielokrotnego zastosowania zmiany.

Myślę, że jasną odpowiedzią, gdy PATCH nie jest idempotentny, jest ten akapit z RFC 5789:

Są również przypadki, w których formaty łatek nie muszą działać ze znanego punktu bazowego (np. Dodawanie wierszy tekstowych do plików dziennika lub nie kolidujących wierszy do tabel bazy danych), w którym to przypadku taka sama ostrożność w żądaniach klientów nie jest potrzebna .

Ponieważ RFC określa, że ​​łatka zawiera pewne „ogólne zmiany” w zasobie, powinniśmy wyjść poza zwykłą zamianę pola. Jeśli zasób jest przeznaczony dla licznika, łata może zażądać jego przyrostu, co oczywiście nie jest idempotet.

PATCHżądania opisują zestaw operacji, które mają być zastosowane do zasobu, jeśli zastosujesz ten sam zestaw operacji dwa razy do tego samego zasobu, wynik może być inny. Jest tak, ponieważ definiowanie operacji zależy od Ciebie. Innymi słowy, musisz zdefiniować reguły łączenia .

Pamiętaj, że PATCHprośba może być wykorzystana do łatania zasobów w wielu różnych formatach, nie tylko w JSON.

Dlatego PATCHżądanie może być idempotentne, jeśli zdefiniujesz reguły scalania jako idempotentne .

Idempotentny przykład:

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

// PATCH request
{
  age: 33
}

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

Przykład nie idempotentny:

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

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

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

W drugim przykładzie użyłem składni „Mongo like”, którą zrekompensowałem do zwiększenia atrybutu. Oczywiście nie jest to idempotentne, ponieważ wielokrotne wysyłanie tego samego żądania spowodowałoby za każdym razem inne wyniki.

Teraz możesz się zastanawiać, czy użycie takiej wymyślonej składni jest prawidłowe. Zgodnie ze standardami jest to:

Różnica między żądaniami PUT i PATCH znajduje odzwierciedlenie w sposobie, w jaki serwer przetwarza encję zamkniętą w celu zmodyfikowania zasobu identyfikowanego przez identyfikator URI żądania. W żądaniu PUT załączony obiekt jest uważany za zmodyfikowaną wersję zasobu przechowywanego na serwerze źródłowym, a klient żąda zastąpienia zapisanej wersji. Jednak w PATCH dołączona jednostka zawiera zestaw instrukcji opisujących, jak należy obecnie zmodyfikować zasób znajdujący się na serwerze źródłowym, aby utworzyć nową wersję.

Być może zastanawiasz się również, czy korzystanie z żądań w ten sposób jest spokojnePATCH , a wiele osób uważa, że ​​tak nie jest, oto dobra odpowiedź z dużą ilością komentarzy na ten temat.