Best practice to map OrientDB ORecordId onto RestFull friendly ID representation

[Bart Van Bos]

Hi OrientDB experts,

We are looking into OrientDB as our persistency solution behind a restful web service, because a GraphDB would be a perfect match for our use case. One of the things we have noticed is that entities (both Vertex and Edges) are uniquely identified by a ORecordId, containing the '#${clusterId}:${clusterPosition}'. In a restful API, based on my personal experience from relational DB's,  you typically have several solutions to identify entities uniquely, for example:

 - UUID's, generated in code and persisted on DB level

 - Long/Int values, generated on DB level incrementally

 - etc...

The problem is that the format "#${clusterId}:${clusterPosition}" is not really URL/REST friendly (example: .../api/user/[#${clusterId}:${clusterPosition}]/address). Do you have any advice/experience on how you would deal with this, keeping in mind that you need a bi-directional mapping between the ORecordId and the "RestFulFriendlyId"?

Any hints and best practices based on experience would be truly appreciated....

Best regards,

Bart

PS: Question also posted on StackOverlfow: https://stackoverflow.com/questions/37424385/best-practice-to-map-orientdb-orecordid-onto-restfull-friendly-id-representation

[scott molinari]

We're looking into using HashID. http://hashids.org/

There are some minor concerns we have still, but theoretically, HashID should get you a hashed Rid, which is also convertible, so it won't take up more storage space (like with a UUID). It will just take a small bit of CPU time.

Please note, this little tool is not in any way a true hash, as in, it makes it very hard to crack the hash. It is more about good obfuscation. If you are at all worried about the Rids being known, this isn't a proper solution.   

Scott

[scott molinari]

Also answered on SE.

Scott

[Eric24]

Actually, I'd say the RIDs are very RESTful, if you do this: .../domain.com/other-segments/{cluster}/{position}/... Since clusters are a "superset" of a specific class (i.e. one class will have one or more clusters), this can be thought of as identifying the target data object by type/record. I'm not sure what backend you're using, but extracting those two URL segments and recombining them to #x:y should be a fairly simple (and maybe mostly automatic) task.