Client side id generation strategy for REST web service

Go To


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?

2012-04-04 18:42
by Zounadire


There is a reason why highly distributed system (like , , etc.) use long UUIDs/hashes while centralized relational databases (or 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
2012-04-04 18:48
by Tomasz Nurkiewicz
Ok. But how can you avoid duplicate creation in case of a lost response - Zounadire 2012-04-04 19:05
@Zounadire: you can't (well, I believe there are some tricks). Note that plain [tag:soap] does not guarantee that as well - Tomasz Nurkiewicz 2012-04-04 19:08
perfect answer - shashankaholic 2012-04-04 20:39