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