It seems to be a common practice nowadays to rely on the database-generated, incremental id.
In one of our projects, we let the client-side (JS) generate the id (using guid/uuid). It leads to interesting consequences. We no longer need to send the form data to the backend immediately. If we want, we can create the object on the client-side, give it a guid, keep editing it and then send it back to the server, with the guid. The server stores the guid and uses it for identification. The same can happen at the same time from another Ruby client that connects to the same API.
This is how an example guid looks like:
"A UUID is 128 bits long, and can guarantee uniqueness across space and time."
"A UUID is an identifier that is unique across both space and time, with respect to the space of all UUIDs. Since a UUID is a fixed size and contains a time field, it is possible for values to rollover (around A.D. 3400, depending on the specific algorithm used)."
My opinion on UUIDs
The area, that I haven't researched much is having distributed database which you sync between the services. From what I know, it's already possible with http://www.datomic.com/.
Ruby has a built-in method:
p SecureRandom.uuid # "2d931510-d99f-494a-8c67-87feb05e1594”
var uuid4 = UUID.create();
// Prints: 896b677f-fb14-11e0-b14d-d11ca798dbac
>>> import uuid >>> # make a UUID based on the host ID and current time >>> uuid.uuid1() UUID('a8098c1a-f86e-11da-bd1a-00112444be1e’)
UUID uuid = UUID.randomUUID();
Also worth reading: http://stackoverflow.com/questions/703035/when-are-you-truly-forced-to-use-uuid-as-part-of-the-design/786541#786541