问题
Let's say I want to build a REST service for making notes that looks something like this:
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
Since I want my service to be indempotent I'm using PUT to create and update my notes, which implies that the ids of new notes are set/generated by the Client.
I thought of using GUIDs/UUIDs but they are pretty long and would make remembering the URLs rather dificult. Also from a database perspective such long string ids can be troublesome from a performance point of view when used as primary key in big tables.
Do you know a good id generation strategy, that generates short ids and of course avoids collisions?
回答1:
There is a reason why highly distributed system (like git, mongodb, etc.) use long UUIDs/hashes while centralized relational databases (or svn for that matter) can simply use ints. There is no easy way of creating short ids on the client-side in a distributed fashion. Either the server handles them or you must live with wasteful ids. Typically they contain encoded timestamp, client/computer id, hashed content, etc.
That's why REST services typically use
POST /notes
for non-idempotent save and then use the output of Location: header in response:
Location: /notes/42
来源：https://stackoverflow.com/questions/10017338/client-side-id-generation-strategy-for-rest-web-service