----- "Devan Goodwin" dgoodwin@rm-rf.ca wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwin dgoodwin@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@rm-rf.ca http://rm-rf.ca _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/24/2010 10:04 AM, Justin Harris wrote:
----- "Devan Goodwin" dgoodwin@rm-rf.ca wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwin dgoodwin@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.
What about the case where we allow a system to pass in their own uuids?
jesus
- -- jesus m. rodriguez | jesusr@redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+
candlepin@lists.stg.fedorahosted.org
-
jesus rodriguez -
Justin Harris