Articles

co to jest operacja Idempotentna?

wprowadzenie

w tym artykule zobaczymy, czym jest operacja idempotent, dlaczego idempotency jest przydatna, i przyjrzymy się idempotency w REST.

Co To jest Idempotencja?

Mówiąc najprościej, możemy wykonać operację idempotentną wiele razy bez zmiany wyniku.

ponadto operacja nie może powodować żadnych skutków ubocznych po pierwszym udanym wykonaniu.

spójrzmy na dwa proste przykłady.

2.1. Wartość bezwzględna

funkcja zwracająca wartość bezwzględną jest idempotentna; bez względu na to, jak często stosujemy ją do tej samej liczby, zawsze zwraca ten sam wynik.

rozważmy funkcję:

wtedy jest prawdziwe:

przykład:

natomiast funkcja odwracająca znak liczby nie jest idempotentna:

następnie:

przykład:

2.2. Zaktualizuj adres

innym praktycznym przykładem operacji idempotentnej byłoby zaktualizowanie danych kontaktowych Użytkownika w systemie. Powiedzmy, że aktualizujemy tylko numer telefonu. Efektem ubocznym tej aktualizacji jest wysłanie wiadomości tekstowej z kodem weryfikacyjnym na nowy numer. Mamy trzy możliwe scenariusze:

  • pierwsza wiadomość aktualizacji została pomyślnie przetworzona, numer został zaktualizowany w systemie, a wiadomość tekstowa została wysłana. Po ponownym wysłaniu Komunikatu o aktualizacji nic się nie stanie. Ponadto wiadomość tekstowa nie jest wysyłana po raz drugi.
  • pierwsza aktualizacja nie powiodła się. System nie jest aktualizowany i nie jest wysyłany żaden SMS. Jeśli druga aktualizacja zakończy się sukcesem, system zostanie zaktualizowany i zostanie wysłana wiadomość tekstowa.
  • pierwsza aktualizacja nie powiodła się. Przed wysłaniem kolejnej aktualizacji użytkownik jest dezaktywowany w systemie. Ponieważ stan systemu się zmienił, druga aktualizacja numeru telefonu nie ma wpływu.

dlaczego Idempotencja?

Idempotencja zapewnia, że to samo żądanie prowadzi do tego samego stanu systemowego i żadna akcja nie zostanie przypadkowo wykonana więcej niż jeden raz.

jako przykład spójrzmy na żądanie nadawcy s, aby wysłać pieniądze za pośrednictwem usługi płatniczej PS do odbiorcy R.

3.1. Przykład nie Idempotentny

oto nie idempotentna wersja żądania:

przy pierwszej próbie s wysyła żądanie, aby wysłać $10 do R. PS odbiera wiadomości; jednak rzeczywisty transfer nie powiedzie się. PS sends zwraca komunikat o błędzie do S, który nie otrzymuje tego komunikatu z powodu awarii sieci.

S nie wie, czy transfer się powiódł, więc próbuje ponownie. Tym razem transfer do R zakończy się powodzeniem, A PS wyśle wiadomość z potwierdzeniem do S. ponownie potwierdzenie nie powiedzie się, A S nie wie, czy transfer się powiódł, czy nie.

dlatego próbuje po raz trzeci. PS otrzymuje wiadomość, traktuje ją jako nową prośbę, wysyła pieniądze do R i zwraca potwierdzenie do S.

to nie jest idempotentna Prośba, ponieważ zamierzaliśmy ponowić tę samą płatność i nie wysłać jej dwa razy.

3.2. Klucz idempotencji

płatności są dobrym przykładem ilustrującym, dlaczego idempotencja jest przydatna. W poprzednim przykładzie widzieliśmy, że płatność na rzecz R jest wykonywana wiele razy, ponieważ S wycofuje się, nie wiedząc, że przelew już się powiódł.

gdyby operacja była idempotentna, tak by nie było. Ale skąd PS wie, że S właśnie powtórzył tę samą płatność i nie chce wysłać drugiej płatności w wysokości 10 $do S?

aby to osiągnąć, S zawiera klucz idempotencji w swojej prośbie do PS. Ten klucz może być, na przykład, jest UUID. Jeśli PS otrzyma żądanie z tym samym kluczem idempotence, wie, że jest to ponowna próba. Jeśli nie widział wcześniej klucza, wie, że jest to nowe żądanie.

spójrzmy na idempotentną wersję poprzedniego przykładu:

tutaj pierwsza próba i pierwsza próba są takie same jak w wersji nie-idempotentnej, z wyjątkiem tego, że żądanie zawiera klucz idempotence (65th68m5 w naszym przykładzie).

ważna różnica to druga próba: PS otrzymuje wiadomość, stwierdza, że wiadomość z tym samym kluczem idempotence została już pomyślnie przetworzona i zwraca potwierdzenie do S bez ponownego wysyłania pieniędzy do R.

tutaj zaletą idempotencji jest to, że S może ponowić próbę tyle razy, ile chce, bez martwienia się o podwójną płatność. PS nie musi się martwić, że s otrzymuje potwierdzenie, ponieważ wie, że s może ponowić próbę w przypadku, gdy nie otrzymał wiadomości.

wadą tego podejścia jest to, że PS musi przechowywać wszystkie odebrane klucze. To może być w porządku, jeśli nie ma wielu próśb; jeśli jednak częstotliwość żądania jest bardzo wysoka, może to być problematyczne. Rozwiązaniem może być wygaśnięcie klucza idempotence po pewnym czasie.

Idempotencja i odpoczynek

4.1. Przegląd

przyjrzyjmy się krótko, jak idempotency odnosi się do czasowników HTTP, które są ważne, aby zrozumieć, gdy chcemy zbudować REST API. Bardzo szczegółowe odniesienie do wszystkich czasowników HTTP można znaleźć w RFC 7231.

poniższa tabela pokazuje, które czasowniki są (lub powinny być) idempotentne.

4.2. Operacje idempotentne

GET, HEAD i OPTION są wyraźnie idempotentne, ponieważ tylko odczytują dane, ale nie tworzą, nie aktualizują ani nie usuwają żadnych zasobów.

PUT jest idempotentny, ponieważ aktualizuje Zasób lub tworzy nowy, jeśli nie istnieje. Jeśli wysłaliśmy tę samą aktualizację wiele razy, zasób nie powinien się zmieniać.

4.3. Operacje nie Idempotentne

POST nie musi być idempotentny, ponieważ tworzy nowy zasób i, jeśli zostanie wywołany ponownie, zwykle tworzy inny zasób. Jednak może być również zaimplementowana jako operacja idempotentna.

operacja poprawki aktualizuje zasób częściowo i niekoniecznie musi być idempotentna. Spójrzmy na przykład, aby lepiej zrozumieć różnicę między PUT I PATCH:

powiedzmy, że chcemy dodać produkt do koszyka w sklepie internetowym. Jeśli korzystamy z PUT, musimy wysłać kompletne dane koszyka, w tym wszystkie elementy, które są już w Koszyku. Dzięki PATCH możemy wysłać tylko element, który ma zostać dodany, a zostanie on dołączony do listy artykułów już w Koszyku.

Jeśli wyślemy żądanie poprawki ponownie, ten sam element zostanie dodany ponownie. Oczywiście, jeśli chodzi o POST, możemy również zaimplementować Patch idempotentny.

4.4. Odpowiedź HTTP

ważne jest, aby pamiętać, że kilka wywołań operacji idempotent niekoniecznie skutkuje tą samą odpowiedzią HTTP.

put, na przykład, zwróci 201 (utworzony), jeśli zasób został utworzony, lub 200 (OK) lub 203 (Brak zawartości), jeśli zasób został zaktualizowany.

a DELETE, na przykład, może zwrócić 200 (OK) lub 204 (Brak zawartości), gdy nastąpi rzeczywiste usunięcie. Kolejne połączenia zwrócą 404 (Nie znaleziono).

podsumowanie

w tym artykule zobaczyliśmy, co oznacza idempotencja, jakie są korzyści z idempotencji i jak odnosi się ona do odpoczynku.

mimo że ogólne znaczenie idempotencji jest łatwe do zrozumienia, może być dość trudne rozważenie wszystkich subtelności, takich jak efekty uboczne i odpowiedzi HTTP podczas projektowania API.