On 10-08-31 8:55 AM, Devan Goodwin wrote:
On Mon, Aug 30, 2010 at 10:56 PM, Bryan Kearney <bkearney@redhat.com> wrote:
  
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.
    
Is that something that should ever happen? Maybe we could cut down to
just the one external 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?
    
That's a good point, I was thinking the id field was handy for...
constructing paths, which clients aren't supposed to do. :) It might
be useful for building object relations when you're POST'ing, but in
that case you'd want the db ID anyhow.

I will continue switching to owner key as the API key.

Cheers,

Devan


  
I would very much rather keep internal id's internal (and not expose them in urls), and use uuid's for the purpose of identifying individual consumers/owners. It may or may not become useful at a later point, but the overhead of separating those is minimal, and it feels right (tm).

-d