-----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 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.
See above
jesus
- --
jesus m. rodriguez | jesusr(a)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 |
+---------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAkx0Hd0ACgkQvJZ57YntiYPM9gCgqrZMcoofI4zcw0oPn5c4VYsO
uKwAn09mRXzNuBMJaKcRYJsWfoztYkcv
=k0nY
-----END PGP SIGNATURE-----