Ich entwerfe einen RESTful-Webdienst mit ROA (Ressourcenorientierte Architektur).

Ich versuche, einen effizienten Weg zu finden, um die Idempotenz für PUT-Anforderungen zu gewährleisten, die neue Ressourcen erstellen, falls der Server den Ressourcenschlüssel festlegt.

ach meinem Verständnis besteht der traditionelle Ansatz darin, eine Art Transaktionsressource wie / CREATE_PERSON zu erstellen. Die Client-Server-Interaktion zum Erstellen einer neuen Personenressource besteht aus zwei Teilen:

Schritt 1: Eindeutige Transaktions-ID zum Erstellen der neuen PERSON-Ressource abrufen :::

**Client request:**
POST /CREATE_PERSON

**Server response:**
200 OK
transaction-id:"as8yfasiob"

Schritt 2: Erstellen Sie die neue Personenressource in einer Anfrage, die mit der Transaktions-ID ::: @ garantiert eindeutig is

**Client request**
PUT /CREATE_PERSON/{transaction_id}
first_name="Big bubba"

**Server response**
201 Created             // (If the request is a duplicate, it would send this
PersonKey="398u4nsdf"   // same response without creating a new resource.  It
                        // would perhaps send an error response if the was used
                        // on a transaction id non-duplicate request, but I have
                        // control over the client, so I can guarantee that this
                        // won't happen)

Das Problem, das ich bei diesem Ansatz sehe, besteht darin, dass zwei Anforderungen an den Server gesendet werden müssen, um einen einzelnen Vorgang zum Erstellen einer neuen PERSON-Ressource auszuführen. Dadurch entstehen Leistungsprobleme, die die Wahrscheinlichkeit erhöhen, dass der Benutzer darauf wartet, dass der Client seine Anforderung abschließt.

Ich habe versucht, Ideen für die Beseitigung des ersten Schritts, wie das Vorabversenden von Transaktions-IDs bei jeder Anfrage, zu finden, aber die meisten meiner Ideen haben andere Probleme oder beinhalten die Beeinträchtigung der Staatenlosigkeit der Anwendung.

Gibt es eine Möglichkeit, dies zu tun?

Bearbeiten:::::

Die Lösung, mit der wir endeten, bestand darin, dass der Client eine UUID erwarb und diese zusammen mit der Anforderung sendete. Eine UUID ist eine sehr große Zahl, die den Platz von 16 Bytes (2 ^ 128) einnimmt. Im Gegensatz zu den intuitiven Vorstellungen von Programmierern ist es gängige Praxis, eine UUID zufällig zu generieren und anzunehmen, dass es sich um einen eindeutigen Wert handelt. Dies liegt daran, dass die Anzahl der möglichen Werte so groß ist, dass die Wahrscheinlichkeit, zufällig zwei gleiche Werte zu generieren, so gering ist, dass dies praktisch unmöglich ist.

Eine Einschränkung ist, dass unsere Clients eine UUID vom Server anfordern GET uuid/). Dies liegt daran, dass wir nicht garantieren können, dass die Umgebung, in der unser Client ausgeführt wird, fehlerfrei ist. Wenn auf dem Client ein Problem wie das Setzen des Zufallszahlengenerators aufgetreten ist, liegt möglicherweise eine UUID-Kollision vor.