2012-04-04 6 views
2

Lassen Sie uns sagen, dass ich für die Anmerkungen bildet einen REST-Dienst aufbauen wollen, die etwa wie folgt aussieht:Client-Seite id Erzeugungsstrategie für REST Web-Service

GET /notes/  // gives me all notes 
GET /notes/{id} // gives the note identified by {id} 
DELETE /notes/{id} // delete note 

PUT /notes/{id} // creates a new note if there is no note identified by {id} 
        // otherwise the existing note is updated 

Da ich meinen Dienst wollen indempotent werden ich PUT bin mit zum Erstellen und Aktualisieren meiner Notizen, was bedeutet, dass die IDs der neuen Notizen vom Client festgelegt/generiert werden.

Ich dachte an die Verwendung von GUIDs/UUIDs, aber sie sind ziemlich lang und würde das Merken der URLs eher schwierig machen. Auch aus der Datenbankperspektive können solche langen String-IDs unter dem Gesichtspunkt der Leistung problematisch sein, wenn sie als Primärschlüssel in großen Tabellen verwendet werden.

Kennen Sie eine gute ID-Generierungsstrategie, die kurze IDs erzeugt und natürlich Kollisionen vermeidet?

Antwort

8

Es gibt einen Grund, warum hochgradig verteilten System (wie , , etc.) verwenden lange UUID/Hashes während zentralisierte relationale Datenbanken (oder was das betrifft) einfach int s nutzen können. Es gibt keine einfache Möglichkeit, kurze IDs auf der Clientseite verteilt zu erzeugen. Entweder behandelt der Server sie oder Sie müssen mit verschwenderischen IDs leben. Typischerweise enthalten sie codierten Zeitstempel, Client/Computer-ID, gehasht Inhalt usw.

, deshalb, typischerweise REST-Service

POST /notes 

für Nicht-idempotent speichern und dann die Ausgabe von Location: Header in Reaktion verwenden verwenden:

Location: /notes/42 
+0

Ok. Aber wie können Sie die doppelte Erstellung im Falle einer verlorenen Antwort vermeiden? – Zounadire

+0

@Zounadire: Sie können nicht (nun, ich glaube, es gibt ein paar Tricks). Beachten Sie, dass plain [tag: soap] das ebenfalls nicht garantiert. –

+0

perfekte Antwort. – shashankaholic