Klucz dodawany jest do cache przed wykonaniem operacji w API, co w sytuacji gdy sytuacja się nie powiedzie w API, a user kliknął X razy i zamiast dostać error , to dostaje 200 bo klucz był już w cache?
Tak jak to zostało wspomniane, dla uproszczenia przykładu całość była trzymana w pamięci, ale docelowo najlepiej mieć to wszystko w globalnej transakcji (tzn. zapis klucza + zmianę stanu systemu).
A co w momencie gdy obok customera mamy np. datę utworzenia/edycji. Wtedy każdorazowe wysłanie PUTa zmieni tą datę „na inną” => nie jest to idempotentne? Jak to traktować :D?
Weź pod uwagę, że to jest całkowicie poboczna operacja związana np. z audytem operacji, niebędącą składową logiki aplikacyjnej/biznesowej, którą spodziewa się wykonać użytkownik w swoim żądaniu - czy zmienisz tę datę czy też nie, nie będzie miało praktycznie żadnego znaczenia. Podobnie można uznać, że np. GET nie jest idempotentny (albo tak naprawdę dowolna metoda, wychodząc poza specyfikację HTTP), w momencie gdy np. loguje informacje o zapytaniu :)
Według mnie to musisz określić jakie wartości są idempotentne tak by ten PUT mógł zostać uznany za "unikalny". Nie wiem czy dobrze zrozumiałem, ale z drugiej strony API mogłoby "obliczyć" taki klucz na podstawie podanych wartości z wybranych property. W tym przypadku bierzemy customera, sprawdzamy ten klucz biorąc pod uwagę wybrane "stałe wartości", które będą mogły porównać klucz z tym trzymanym w cachu czy gdziekolwiek indziej. Patrząc prostolinijnie na twoje pytanie, ja bym uznał, że nie jest idempotentne.
Spoko materiał, jak zawsze na wysokim poziomie👍
Bardzo podoba mi się nazwa projektu "Szwindel", daje lajka :D
Super ogarniety temat. Unikatowy a nie unikalny brzmi zdecydowanie lepiej ;)
To prawda, ładniejsze słowo :D
Zrozumiałe wyjaśnienie 😁 może teraz testy kontraktowe?
Może kiedyś się pojawią, aczkolwiek to jest bardzo rozbudowany temat, prawdopodobnie na kilka godzin materiału :)
Klucz dodawany jest do cache przed wykonaniem operacji w API, co w sytuacji gdy sytuacja się nie powiedzie w API, a user kliknął X razy i zamiast dostać error , to dostaje 200 bo klucz był już w cache?
Tak jak to zostało wspomniane, dla uproszczenia przykładu całość była trzymana w pamięci, ale docelowo najlepiej mieć to wszystko w globalnej transakcji (tzn. zapis klucza + zmianę stanu systemu).
A co w momencie gdy obok customera mamy np. datę utworzenia/edycji.
Wtedy każdorazowe wysłanie PUTa zmieni tą datę „na inną” => nie jest to idempotentne?
Jak to traktować :D?
Weź pod uwagę, że to jest całkowicie poboczna operacja związana np. z audytem operacji, niebędącą składową logiki aplikacyjnej/biznesowej, którą spodziewa się wykonać użytkownik w swoim żądaniu - czy zmienisz tę datę czy też nie, nie będzie miało praktycznie żadnego znaczenia. Podobnie można uznać, że np. GET nie jest idempotentny (albo tak naprawdę dowolna metoda, wychodząc poza specyfikację HTTP), w momencie gdy np. loguje informacje o zapytaniu :)
Według mnie to musisz określić jakie wartości są idempotentne tak by ten PUT mógł zostać uznany za "unikalny". Nie wiem czy dobrze zrozumiałem, ale z drugiej strony API mogłoby "obliczyć" taki klucz na podstawie podanych wartości z wybranych property. W tym przypadku bierzemy customera, sprawdzamy ten klucz biorąc pod uwagę wybrane "stałe wartości", które będą mogły porównać klucz z tym trzymanym w cachu czy gdziekolwiek indziej. Patrząc prostolinijnie na twoje pytanie, ja bym uznał, że nie jest idempotentne.
@@rvN7HD to już podchodzi trochę pod ETag :)
Hi, why did you discontinued the English content 😢.?
Hey, not enough spare time to run the 2 distinct channels :(
@@DevMentorsPLOkay😢. I will miss your great content. Wish you the best.