HATEOAS Patch

Bryan Kearney bkearney at redhat.com
Tue Aug 24 23:20:17 UTC 2010


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 at 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 at 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



More information about the candlepin mailing list