Hallo,
ich setzte mich gerade mit dem Thema „API idempotence“ auseinander, und wollte euch zu meinem besseren Verständnis eigene Fragen stellen ob ich es richtig verstehe:
1) „idempotence“ ist vor allem eine Technische Betrachtung der API und weniger Domain spezifisch
Damit meine ich das damit v.a. auf technischer ebene adressiert wird, dass ein Request zum System den Zustand (des Systems/der Daten) nicht irrtümlich ändert. Z.b. Wenn die Response verloren geht, kann der Nutzer/Client nochmals den genau gleichen Request senden, und sich bei einer idempotenten API sicher sein, das nicht versehentlich ein unerwünschte Ereignisse auslöst wird (e.g.: 2 mal dasselbe Produkt bestellen/bezahlen).
Stimmt diese Sichtweise? Oder gibt es auch eine Domänen spezifische Aspekt? Klar schützt man die Domäne mit, aber auf einem Technischen level. mMn sollte die Domänen Seite eher ducrh Business Rules adressiert, verhindert werden.
2) Die Technische Implementierung von idempotence ist nicht leicht 😉
So wie ich es versteh, muss das vom Client „mit Unterstützt“ werden, in dem beim Request ein „einzigartiger Schlüssel“ (e.g.: UUID) mit gesendet wird. Dieser kann dann vom Server genutzt werden um zu vergleichen ob er diesen Request schon mal bekommen hat.
Nein -> er verarbeitet die Anfrage, und fügt in eine Tabelle den „einzigartiger Schlüssel“ (e.g.: UUID) + die Response ein, und sendet die Reponse zurück.
Ja -> er kann mit der abfrage der Tabelle die bereits bekannte Response zurück schicken.
Frage: Gibt es auch andere Implementierungs-Konzepte?
(Den Ganzen Request speichern könnte ja sehr in den Speicher gehen, und müsste ggf Time Stamps, Signaturen etc irgendwie berücksichtigen)
2.1) idempotence wird nie unendlich gewährt.
Der Client schickt mit dem „einzigartiger Schlüssel“ (e.g.: UUID) auch eine Validity Time (z.B.: 1 Tag) + time stamp für den dieser Request gültig ist.
Der Server Speichert sich diesen wert + wann der Request verarbeitet wurde. Damit er alle Einträge aus seiner Tabelle löschen kann, die älter als Request Time + Validity Time Range sind.
(Alternative kann man auch sagen, dass der Server selbst einen Default hat, wie lange er die Einträge als gültig erachtet)
Frage: Stimmt das so?
Gibt es noch andere Konzepte die idempotence zeitlich zu limitieren? (oder macht man das irgendwo nicht?)
Wie bestimmt man die Zeit wie lange man idempotence gewähren will?
Was sagt ihr dazu?
ich setzte mich gerade mit dem Thema „API idempotence“ auseinander, und wollte euch zu meinem besseren Verständnis eigene Fragen stellen ob ich es richtig verstehe:
1) „idempotence“ ist vor allem eine Technische Betrachtung der API und weniger Domain spezifisch
Damit meine ich das damit v.a. auf technischer ebene adressiert wird, dass ein Request zum System den Zustand (des Systems/der Daten) nicht irrtümlich ändert. Z.b. Wenn die Response verloren geht, kann der Nutzer/Client nochmals den genau gleichen Request senden, und sich bei einer idempotenten API sicher sein, das nicht versehentlich ein unerwünschte Ereignisse auslöst wird (e.g.: 2 mal dasselbe Produkt bestellen/bezahlen).
Stimmt diese Sichtweise? Oder gibt es auch eine Domänen spezifische Aspekt? Klar schützt man die Domäne mit, aber auf einem Technischen level. mMn sollte die Domänen Seite eher ducrh Business Rules adressiert, verhindert werden.
2) Die Technische Implementierung von idempotence ist nicht leicht 😉
So wie ich es versteh, muss das vom Client „mit Unterstützt“ werden, in dem beim Request ein „einzigartiger Schlüssel“ (e.g.: UUID) mit gesendet wird. Dieser kann dann vom Server genutzt werden um zu vergleichen ob er diesen Request schon mal bekommen hat.
Nein -> er verarbeitet die Anfrage, und fügt in eine Tabelle den „einzigartiger Schlüssel“ (e.g.: UUID) + die Response ein, und sendet die Reponse zurück.
Ja -> er kann mit der abfrage der Tabelle die bereits bekannte Response zurück schicken.
Frage: Gibt es auch andere Implementierungs-Konzepte?
(Den Ganzen Request speichern könnte ja sehr in den Speicher gehen, und müsste ggf Time Stamps, Signaturen etc irgendwie berücksichtigen)
2.1) idempotence wird nie unendlich gewährt.
Der Client schickt mit dem „einzigartiger Schlüssel“ (e.g.: UUID) auch eine Validity Time (z.B.: 1 Tag) + time stamp für den dieser Request gültig ist.
Der Server Speichert sich diesen wert + wann der Request verarbeitet wurde. Damit er alle Einträge aus seiner Tabelle löschen kann, die älter als Request Time + Validity Time Range sind.
(Alternative kann man auch sagen, dass der Server selbst einen Default hat, wie lange er die Einträge als gültig erachtet)
Frage: Stimmt das so?
Gibt es noch andere Konzepte die idempotence zeitlich zu limitieren? (oder macht man das irgendwo nicht?)
Wie bestimmt man die Zeit wie lange man idempotence gewähren will?
Was sagt ihr dazu?