On Tue, Aug 24, 2010 at 4:03 PM, Bryan Kearney <bkearney(a)redhat.com> wrote:
On 08/24/2010 09:49 AM, Devan Goodwin 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.
I am not following the issue here.
Basically you'd get HATEOAS form of a consumer:
{'href' = '/consumers/7129-7817-1974', id = '7129-7817-1974'}
And then when you GET /consumers/7129-7817-1974, your json would now contain:
{id = 1, uuid = '7129-7817-1974'}
So the 'id' value would change on you, which is very weird.
I do like the idea of the internal/external keys. am I the only one?
Would be ok if we weren't hopping around between HATEOAS form (which I
assume we want to always be "id" + "href" for any object, and
"id"
should be what you use in the URL), and another form where ID means
something else. For all objects except consumers/owners, "id" is fine,
but for those two, not sure what to do.
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca