On 10-08-31 8:55 AM, Devan Goodwin wrote:
On Mon, Aug 30, 2010 at 10:56 PM, Bryan
Kearney<bkearney(a)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