Client-Side Generation Strategy for REST Web Service
Let's say I want to create a REST service for taking 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 unresponsive, I use PUT to create and update my notes, which means the new note IDs are set / created by the client.
I was thinking about using GUID / UUID, but they are quite long and make me remember urls rather dificult. Also from a database perspective, such long row IDs can be troublesome from a performance perspective when used as a primary key in large tables.
Do you know a good ID generation strategy that generates short IDs and of course avoids conflicts?
source to share
There is a reason why a highly distributed system (e.g. git, mongodb etc ..) use long UUIDs / hashes, while centralized relational databases (or svnfor that matter) might just use int
s. There is no easy way to generate short client side identifiers in a distributed manner. Either the server handles them, or you have to live with wasteful IDs. They usually contain an encoded timestamp, client / computer ID, hashed content, etc.
What REST services are typically used for
POST /notes
for non-idempotent persistence, then use header output Location:
in response:
Location: /notes/42
source to share