Was heißt es, wenn ein Endpoint idempotent ist, und wie machst du einen Create-Endpoint idempotent?

Ein idempotenter Endpoint liefert dasselbe Ergebnis, egal ob er einmal oder fünfmal mit derselben Eingabe aufgerufen wird. GET, PUT und DELETE sind von Natur aus idempotent, POST ist es nicht. Einen Create-Endpoint machst du idempotent, indem der Client einen eindeutigen Idempotency Key schickt, du diesen Key in derselben Transaktion wie die erzeugte Ressource speicherst und bei jeder Wiederholung das ursprüngliche Ergebnis zurückgibst.

Idempotent heißt, zweimal aufrufen hinterlässt das System im selben Zustand wie einmal aufrufen. PUT ist idempotent, weil du den Endzustand angibst; POST ist es meistens nicht, weil jeder Aufruf mach noch eins bedeutet. Für einen Create-Endpoint lasse ich den Client einen Key erzeugen, typischerweise eine UUID, und ihn als Header schicken. Serverseitig lege ich diesen Key in einer Tabelle mit Unique Constraint ab, und ich schreibe ihn in derselben Transaktion wie die Ressource selbst, denn wenn diese beiden Commits auseinanderlaufen können, ist das ganze Verfahren Dekoration. Kommt derselbe Key noch mal, schlage ich ihn nach und gebe die ursprüngliche Antwort mit dem ursprünglichen Status zurück. Was viele übersehen, ist der gleichzeitige Fall, in dem zwei Retries in derselben Millisekunde landen. Der Unique Index löst das: Das zweite Insert schlägt fehl, ich fange die Verletzung ab und lese den Gewinner zurück, statt einen Fehler zu werfen. Ich habe das für einen Payment-Endpoint gebaut, nachdem wir jemanden bei einem Netzwerkaussetzer doppelt belastet hatten.