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.
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.
Thoughts?
Cheers,
Devan
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
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
On 08/31/2010 07:55 AM, Devan Goodwin wrote:
On Mon, Aug 30, 2010 at 10:56 PM, Bryan Kearneybkearney@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.
I dont have a strong example one way or the other.. but I have a feeling we will need to change the external ids.. ont know why.. just do.
-- bk
On 10-08-31 8:55 AM, Devan Goodwin wrote:
On Mon, Aug 30, 2010 at 10:56 PM, Bryan Kearneybkearney@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
candlepin@lists.stg.fedorahosted.org
-
Bryan Kearney -
Devan Goodwin -
Dmitri Dolguikh