On 08/24/2010 03:30 PM, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/24/2010 03:08 PM, Devan Goodwin wrote:
> 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.
why can't this be:
{'href' = '/consumers/7129-7817-1974', uuid = '7129-7817-1974'}
or
{'href' = '/consumers/7129-7817-1974', id = 1}
>
I would be fine with this.
-- bk