On 08/30/2010 04:18 PM, Devan Goodwin wrote:
Began the process of switching to use owner keys in the owner resource URLs and got to thinking, instead of making two entities behave differently (in having both a numeric database ID + a possibly externally generated string ID), why don't we make consumer URLs use the objects ID instead of UUID.
For each of these, I think the real ID will be the external one. The only benefit of having the internal one is that we can change the externaa ID.
All our resources would then behave almost identically. This would cleanup a problem I mailed about last week related to HATEOAS ID serialization. The consumer UUID and owner key would still remain in the database and JSON, just not be used as the "ID" as far as our REST API is concerned.
The only downside I can think of is clients (which store the UUID locally) would now have to do an initial call to lookup their consumer ID, but this could easily be done by a client library transparently, and could be cached if desired. Additionally if we're going down the HATEOAS path, the impact on integrating apps and clients should be minimal as hopefully, they won't need to be assuming URL paths.
If they all use the href field.. how does this improve/not improve for them?
-- bk