----- "Devan Goodwin" <dgoodwin(a)rm-rf.ca> wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwin
<dgoodwin(a)rm-rf.ca>
wrote:
> Still to do:
> - Possibly serialize ID along with href. (watch out for
consumer.uuid
> and soon, owner.key.)
Do we want this HATEOAS form of an object to contain "id" and "href"
both? My concern with the ID is that if you serialize a consumer, you
have an "id" which is a numeric database ID, but the "uuid" is the
actual ID we use in all URLs. It seems all kinds of wrong to return
"id" = "uuid" when the HATEOAS serialization kicks in, and then
"id"
=
int when you follow that link.
Perhaps consumer.id needs to go away?
Yeah this is a good point - if consumer uuid truly is unique, then it seems
to me that it is an appropriate primary key in the db as well.
We were talking about making owner.key the URL identifier for owners
as well, should that also become owner.id and behave just like
consumer UUIDs?
+1 for this as well. But in both of these scenarios I think that it will involve
a little more error messaging with the client, because in both of these scenarios the
client can provide the primary key, which can easily mean collisions. Not a big deal to
handle, but it does mean that the client should be able to display an error message
saying
that the provided (uuid/key) is in use and a different one should be provided.
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin