Darf der Client wiederholen?

Worum es geht

Netzwerke sind unzuverlässig. Manchmal kommt eine Antwort nicht an, manchmal ist ein Token abgelaufen, manchmal ist die Datenbank kurz weg. Dann stellt sich die Frage: Darf ich die Anfrage einfach noch einmal schicken?

Eine Operation heißt idempotent, wenn zweimal ausführen dasselbe Ergebnis hat wie einmal. Solche Operationen darfst du gefahrlos wiederholen. CDMS kennt keinen Idempotenzschlüssel, mit dem der Server Wiederholungen selbst erkennt. Die Entscheidung liegt beim Client.

Welche Operation ist wiederholbar?

Operation	wiederholbar?	Was eine Wiederholung bewirkt
`POST /read/{id}`, `GET /read/{id}`, `POST /query`, `POST /{id}/history`	ja	nichts, es wird nur gelesen
`PUT /update/{id}`	ja	derselbe Endzustand; `_updatedOn` und bei auditierten Modellen eine weitere Revision
`PATCH /update/{id}`	ja	derselbe Endzustand, sofern die Werte absolut sind
`DELETE /delete/{id}`	ja	die zweite Anfrage liefert 404, weil das Objekt schon weg ist
`POST /{id}/rollback/{revision}`	ja	derselbe Inhalt, eine weitere Revision
`POST /create`	nein	ein zweites Objekt mit neuer `id`
`POST /create` bei einem Singleton	ja	die zweite Anfrage liefert 400 `object-already-exists\|use-update`

Zwei Einschränkungen bei PUT und PATCH:

Listeneinträge ohne id sind neue Kinder. Jede Wiederholung legt sie neu an, und die bei der letzten Anfrage angelegten fallen aus der Liste (mit DELETE-Flag werden sie gelöscht). Schicke bestehende Kinder immer mit id.
Hochgeladene Dateien werden bei jeder Wiederholung erneut gespeichert. Bei auditierten Datei-Modellen entsteht dabei jedes Mal eine weitere Version.

Was die Antwort über den Stand sagt

Weil CDMS vor der Antwort festschreibt und bei jedem Fehler zurückrollt, verrät die Antwort, was gespeichert ist. Siehe Ein Request, eine Transaktion.

Nach welcher Antwort was tun?

Antwort	Gespeichert? Was tun?
2xx	gespeichert. Nicht wiederholen.
200 mit `CDMS_CREATE_SUCCEEDED_READ_FAILED`	angelegt, die `id` steht in der Antwort. Nicht noch einmal anlegen.
401	nichts. Token erneuern, dann dieselbe Anfrage wiederholen, auch ein `create`.
400, 403, 404, 422	nichts. Eine unveränderte Wiederholung scheitert genauso; erst die Ursache beheben.
409 `already-exists` oder `database-integrity-failed`	nichts. Die gespeicherten Daten stehen im Weg; eine unveränderte Wiederholung scheitert genauso.
409 `CDMS_OPTIMISTIC_LOCK_CONFLICT`	nichts. Objekt neu lesen, Änderung neu aufsetzen, dann wiederholen.
503	nichts. Die Datenbank ist nicht erreichbar oder hat eine Sperre nicht rechtzeitig vergeben. Nach einer Pause wiederholen.
500	nichts. Ein Fehler im Server; eine Wiederholung hilft meist nicht.
keine Antwort (Zeitüberschreitung, Verbindung abgebrochen)	unklar: vielleicht festgeschrieben, vielleicht nicht

Bei 401 hat CDMS die Anfrage gar nicht erst verarbeitet: Die Filterkette weist ein ungültiges oder abgelaufenes Token ab, bevor irgendetwas geschrieben wird. Siehe Der Weg des Tokens.

„Nichts gespeichert“ gilt für die Datenbank. Dateiinhalte und Anfragen über zwei Datenbanken haben eigene Regeln: Dateien und Transaktion und Keine Atomarität über zwei Datenbanken.

Keine Antwort nach einem create

Das ist der einzige Fall, bei dem eine blinde Wiederholung Schaden anrichtet. Der Commit kann gelungen sein, und nur die Antwort ist verloren gegangen.

1

Client→CDMS
POST /order/create mit orderNr: A-1000
2

Client
keine Antwort, Zeitüberschreitung
3

Client→CDMS
sucht zuerst: POST /order/query mit Filter orderNr EQ A-1000
4

Client
Treffer → das Objekt existiert schon, seine id übernehmen
5

Client→CDMS
kein Treffer → create wiederholen

Damit das funktioniert, braucht das Modell ein Feld, an dem du das Objekt wiedererkennst: eine Auftragsnummer, eine vom Client erzeugte Referenz, eine E-Mail-Adresse. Am sichersten ist eine Eindeutigkeitsregel auf diesem Feld: Dann scheitert ein doppeltes create mit 409 already-exists statt ein zweites Objekt anzulegen.

Fallen

Wie es weitergeht

Die Klammer um eine Anfrage: Ein Request, eine Transaktion
Angelegt, aber nicht zurückgelesen: Anlegen und Zurücklesen: STRICT oder LENIENT
Konflikte: Gleichzeitige Änderungen
Alle Statuscodes: Landkarte der Statuscodes