Owner Keys and Consumer UUIDs

Bryan Kearney bkearney at redhat.com
Tue Aug 31 01:56:32 UTC 2010


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




More information about the candlepin mailing list