Attached is a work in progress patch for HATEOAS support.
In terms of what it does, I think it's exactly what we want. We have one custom serializer which we register for all our linkable types. This serializer can check the context it's in. If serializing a root object, we want to just proceed with normal serialization. (more on this later) If serializing within another object, we want to manually output our JSON with just an 'href'. Not added yet but we'll do exactly the same if within a collection, and there is a context for this as well.
As far as making it happen it got a little messy. I had to dig way into Jackson internals and the end result was creation of our own SerializerProvider and SerializerFactory sub-classes. These are both configured on the ObjectMapper, and then once in the serializer it assumes the provider configured is our's and casts it. (if you tried to use our custom serializer in an object mapper that didn't use our serializer provider and factory, this would error out fast, but not a problem generally as far as I've seen) Worst of all, there is a 30-odd line method copied in our SerializerFactory that comes straight from it's grandparent class in Jackson.
All of the above is done so we can register customer serializer, and then within that serializer, have a method call available to us which circumvents the custom serializers registered and just moves on to use the default. (thus preventing infinite recursion with our serializer) I tried everything I could come up with to manually create the default object serializer but it's a BeanSerailizer in Jackson and it's creation is non-trivial.
So while this code doesn't thrill me, it's isolated and not something that can spread throughout the code base, and the end result JSON appears to be spot on for what we want. If in the future it were to become unmaintainable or break, we could work out another solution, or do custom serializers for all our objects, and just keep the JSON consistent. As such I think it's worth proceeding with this, provided there are no hidden gremlins.
Still to do: - Possibly serialize ID along with href. (watch out for consumer.uuid and soon, owner.key.) - Linkify collections. (just need to check for context in CandlepinSerializer) - Expand to more model classes. (certs, subscriptions, possibly a couple others) - Add top level links to resources. - Fix *everything*, cuke/rspec, RHSM, etc.
Still a bit of work to be done to finish it off, particularly in the last step. This patch has been pushed to the hateros2 branch.
There is possibility here for a patch submission to Jackson I think. This solution isn't it, but I think a new annotation that would automagically do most of the above might be.
Cheers,
Devan
----- "Devan Goodwin" dgoodwin@rm-rf.ca wrote:
Attached is a work in progress patch for HATEOAS support.
In terms of what it does, I think it's exactly what we want. We have one custom serializer which we register for all our linkable types. This serializer can check the context it's in. If serializing a root object, we want to just proceed with normal serialization. (more on this later) If serializing within another object, we want to manually output our JSON with just an 'href'. Not added yet but we'll do exactly the same if within a collection, and there is a context for this as well.
As far as making it happen it got a little messy. I had to dig way into Jackson internals and the end result was creation of our own SerializerProvider and SerializerFactory sub-classes. These are both configured on the ObjectMapper, and then once in the serializer it assumes the provider configured is our's and casts it. (if you tried to use our custom serializer in an object mapper that didn't use our serializer provider and factory, this would error out fast, but not a problem generally as far as I've seen) Worst of all, there is a 30-odd line method copied in our SerializerFactory that comes straight from it's grandparent class in Jackson.
All of the above is done so we can register customer serializer, and then within that serializer, have a method call available to us which circumvents the custom serializers registered and just moves on to use the default. (thus preventing infinite recursion with our serializer) I tried everything I could come up with to manually create the default object serializer but it's a BeanSerailizer in Jackson and it's creation is non-trivial.
So while this code doesn't thrill me, it's isolated and not something that can spread throughout the code base, and the end result JSON appears to be spot on for what we want. If in the future it were to become unmaintainable or break, we could work out another solution, or do custom serializers for all our objects, and just keep the JSON consistent. As such I think it's worth proceeding with this, provided there are no hidden gremlins.
Maybe we established this a while back, but does this mean that JSON is our only supported format?
Still to do:
- Possibly serialize ID along with href. (watch out for consumer.uuid
and soon, owner.key.)
- Linkify collections. (just need to check for context in
CandlepinSerializer)
- Expand to more model classes. (certs, subscriptions, possibly a
couple others)
- Add top level links to resources.
- Fix *everything*, cuke/rspec, RHSM, etc.
Still a bit of work to be done to finish it off, particularly in the last step. This patch has been pushed to the hateros2 branch.
There is possibility here for a patch submission to Jackson I think. This solution isn't it, but I think a new annotation that would automagically do most of the above might be.
Cheers,
Devan
-- 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/18/2010 09:56 AM, Justin Harris wrote:
Maybe we established this a while back, but does this mean that JSON is our only supported format?
I thought that was the case when we changed to jackson.
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 | +---------------------------------------------+
On Wed, Aug 18, 2010 at 11:18:12AM -0400, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/18/2010 09:56 AM, Justin Harris wrote:
Maybe we established this a while back, but does this mean that JSON is our only supported format?
I thought that was the case when we changed to jackson.
jackson still uses the same xml annotations, so technically they both work. though i doubt anyone has confirmed that in a while.
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 | +---------------------------------------------+
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxr+bQACgkQvJZ57YntiYOMTgCgySf9Hd9RYOazZZgOx1jk9Hsc 0E4An0USC+wummv4brhXX6c+RrmO0/0G =ECO1 -----END PGP SIGNATURE----- _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
-James
On 08/18/2010 11:21 AM, James Bowes wrote:
On Wed, Aug 18, 2010 at 11:18:12AM -0400, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/18/2010 09:56 AM, Justin Harris wrote:
Maybe we established this a while back, but does this mean that JSON is our only supported format?
I thought that was the case when we changed to jackson.
jackson still uses the same xml annotations, so technically they both work. though i doubt anyone has confirmed that in a while.
I think it is a defacto design decision. Jesus, does that raise any issues for you?
-- bk
On Thu, Aug 19, 2010 at 08:05:02PM -0400, Bryan Kearney wrote:
On 08/18/2010 11:21 AM, James Bowes wrote:
On Wed, Aug 18, 2010 at 11:18:12AM -0400, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/18/2010 09:56 AM, Justin Harris wrote:
Maybe we established this a while back, but does this mean that JSON is our only supported format?
I thought that was the case when we changed to jackson.
jackson still uses the same xml annotations, so technically they both work. though i doubt anyone has confirmed that in a while.
I think it is a defacto design decision. Jesus, does that raise any issues for you?
I have no issues with us just supporting JSON. I don't care for XML anyway :)
jesus
On 08/20/2010 09:05 AM, Jesus Rodriguez wrote:
On Thu, Aug 19, 2010 at 08:05:02PM -0400, Bryan Kearney wrote:
On 08/18/2010 11:21 AM, James Bowes wrote:
On Wed, Aug 18, 2010 at 11:18:12AM -0400, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/18/2010 09:56 AM, Justin Harris wrote:
Maybe we established this a while back, but does this mean that JSON is our only supported format?
I thought that was the case when we changed to jackson.
jackson still uses the same xml annotations, so technically they both work. though i doubt anyone has confirmed that in a while.
I think it is a defacto design decision. Jesus, does that raise any issues for you?
I have no issues with us just supporting JSON. I don't care for XML anyway :)
jesus
I've been watching this discussion with some interest. While FreeIPA is not RESTful in its current incarnation, we are not that far from it if we were to transform much of what we do with Hash params (for Ajax, much better to have params start with '#' as opposed to '?' ) we could easily transform to a RESTFul approach,. and we are discussing it.
As far as HATEOAS goes, we currently have plugin in system that drives the objects exposed via the URL scheme. We recently added a new plugin with exposed the meta data of the other plugins, and I would think that this would be our starting point.
Is this the right concept: ideally, a user would start at a top level URL, like /ipa/json and get back a page that says: here are the list of objects we manage, and that list would be in hyperlinks to the next level objects, os tha, say users, would be: https://server/ipa/json/users and groups would be https://server/ipa/json/groups...and so on in RESTful form?
Does it need to be at the top of the hierarchy? Obviously, if you put multiple apps on the same port on a server, the non-app specific part of the URL (https://server) should provide enumeration of the apps under it, and so if Candlepin and FreeIPA were on the same server, we would ideally have som sort of info at the top level that lists https://server/ipa and https://server/candlepin (I'm ignoring the Java vs Apache issue for now, we could do that with mod_jk or something).
Of course, one major difference is that we Have UI right now and you don't. So, would that top level URL have to be smart enough to provide both a UI and non UI based directive for the installed applications on that Server? Something like
<div style="display:none" id="discovery"> <a href="/discovery">Web services on this server.</a> </div>
It could asl be put in a header or some other approach.
Which a JQuery selector could find with $("discovery a"). Obviously, this scheme implies some XML parsing is required.
So, what is the goal of implementing HATEOAS in Candlepin, other than it is a good design decision? Is it part of a larger integration scheme, and if not, should it be?
On 08/20/2010 09:43 AM, Adam Young wrote:
On 08/20/2010 09:05 AM, Jesus Rodriguez wrote:
On Thu, Aug 19, 2010 at 08:05:02PM -0400, Bryan Kearney wrote:
On 08/18/2010 11:21 AM, James Bowes wrote:
On Wed, Aug 18, 2010 at 11:18:12AM -0400, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/18/2010 09:56 AM, Justin Harris wrote:
Maybe we established this a while back, but does this mean that JSON is our only supported format?
I thought that was the case when we changed to jackson.
jackson still uses the same xml annotations, so technically they both work. though i doubt anyone has confirmed that in a while.
I think it is a defacto design decision. Jesus, does that raise any issues for you?
I have no issues with us just supporting JSON. I don't care for XML anyway :)
jesus
I've been watching this discussion with some interest. While FreeIPA is not RESTful in its current incarnation, we are not that far from it if we were to transform much of what we do with Hash params (for Ajax, much better to have params start with '#' as opposed to '?' ) we could easily transform to a RESTFul approach,. and we are discussing it.
As far as HATEOAS goes, we currently have plugin in system that drives the objects exposed via the URL scheme. We recently added a new plugin with exposed the meta data of the other plugins, and I would think that this would be our starting point.
Is this the right concept: ideally, a user would start at a top level URL, like /ipa/json and get back a page that says: here are the list of objects we manage, and that list would be in hyperlinks to the next level objects, os tha, say users, would be: https://server/ipa/json/users and groups would be https://server/ipa/json/groups...and so on in RESTful form?
First off.. everyone argues not to care about urls. But.. for this case.. an arguement could be that a users groups: /users/{uuid}/groups
would return to you a collection of group refs which point you at:
/groups/{uuid}
Note, I left json off since this _should_ be an accept header.
Does it need to be at the top of the hierarchy? Obviously, if you put multiple apps on the same port on a server, the non-app specific part of the URL (https://server) should provide enumeration of the apps under it, and so if Candlepin and FreeIPA were on the same server, we would ideally have som sort of info at the top level that lists https://server/ipa and https://server/candlepin (I'm ignoring the Java vs Apache issue for now, we could do that with mod_jk or something).
Yes.. in theory.. going to / would give me a map of all the things I could do. I wonder the value of solving that in the standard case tho.
Of course, one major difference is that we Have UI right now and you don't. So, would that top level URL have to be smart enough to provide both a UI and non UI based directive for the installed applications on that Server? Something like
<div style="display:none" id="discovery"> <a href="/discovery">Web services on this server.</a> </div>
based on the accept_header! If I go to your root level as say I want JSON... why give me html? (Snarkiness implied.. it is friday!)
It could asl be put in a header or some other approach.
Which a JQuery selector could find with $("discovery a"). Obviously, this scheme implies some XML parsing is required.
So, what is the goal of implementing HATEOAS in Candlepin, other than it is a good design decision? Is it part of a larger integration scheme, and if not, should it be?
The desire in adopting this is to support a better rest implementation for folks to create truely decoupled clients. If you create a client and hardcode to my URL pattern, then there is no realy difference to XMLRPC, XML over HTTP, etc.
-- bk
On 08/18/2010 11:21 AM, James Bowes wrote:
On Wed, Aug 18, 2010 at 11:18:12AM -0400, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/18/2010 09:56 AM, Justin Harris wrote:
Maybe we established this a while back, but does this mean that JSON is our only supported format?
I thought that was the case when we changed to jackson.
jackson still uses the same xml annotations, so technically they both work. though i doubt anyone has confirmed that in a while.
Sorry.. Justin.. any issues with this?
-- bk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/18/2010 08:57 AM, Devan Goodwin wrote:
Attached is a work in progress patch for HATEOAS support.
[snip]
As far as making it happen it got a little messy. I had to dig way into Jackson internals and the end result was creation of our own SerializerProvider and SerializerFactory sub-classes. These are both configured on the ObjectMapper, and then once in the serializer it assumes the provider configured is our's and casts it. (if you tried to use our custom serializer in an object mapper that didn't use our serializer provider and factory, this would error out fast, but not a problem generally as far as I've seen) Worst of all, there is a 30-odd line method copied in our SerializerFactory that comes straight from it's grandparent class in Jackson.
Did you comment the method to show that it came from its grandparent class?
All of the above is done so we can register customer serializer, and then within that serializer, have a method call available to us which circumvents the custom serializers registered and just moves on to use the default. (thus preventing infinite recursion with our serializer) I tried everything I could come up with to manually create the default object serializer but it's a BeanSerailizer in Jackson and it's creation is non-trivial.
So while this code doesn't thrill me, it's isolated and not something that can spread throughout the code base, and the end result JSON appears to be spot on for what we want. If in the future it were to become unmaintainable or break, we could work out another solution, or do custom serializers for all our objects, and just keep the JSON consistent. As such I think it's worth proceeding with this, provided there are no hidden gremlins.
Fair enough.
[snip]
Comments on patch:
* getHref() seems to 'hardcode' paths i.e. "/consumers/", is there any way to get these values from the annotations?
* I like the use of reflection in CandlepinSerializer very nice :D
* can you add a link to the source for jackson's beanserializerFactory in your CandlepinSerializerFactory?
* SerializerProvider looks ok except is has an _serializerFactory and _config. Is those jackson variables? If so, we'll need to get checkstyle to ignore this file somehow
I like it so far, my biggest beef is with the Href() methods explicitly listing urls in them vs using some sort of annotations.
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 | +---------------------------------------------+
On Wed, Aug 18, 2010 at 12:45 PM, Jesus M. Rodriguez jesusr@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/18/2010 08:57 AM, Devan Goodwin wrote:
Attached is a work in progress patch for HATEOAS support.
[snip]
As far as making it happen it got a little messy. I had to dig way into Jackson internals and the end result was creation of our own SerializerProvider and SerializerFactory sub-classes. These are both configured on the ObjectMapper, and then once in the serializer it assumes the provider configured is our's and casts it. (if you tried to use our custom serializer in an object mapper that didn't use our serializer provider and factory, this would error out fast, but not a problem generally as far as I've seen) Worst of all, there is a 30-odd line method copied in our SerializerFactory that comes straight from it's grandparent class in Jackson.
Did you comment the method to show that it came from its grandparent class?
All of the above is done so we can register customer serializer, and then within that serializer, have a method call available to us which circumvents the custom serializers registered and just moves on to use the default. (thus preventing infinite recursion with our serializer) I tried everything I could come up with to manually create the default object serializer but it's a BeanSerailizer in Jackson and it's creation is non-trivial.
So while this code doesn't thrill me, it's isolated and not something that can spread throughout the code base, and the end result JSON appears to be spot on for what we want. If in the future it were to become unmaintainable or break, we could work out another solution, or do custom serializers for all our objects, and just keep the JSON consistent. As such I think it's worth proceeding with this, provided there are no hidden gremlins.
Fair enough.
[snip]
Comments on patch:
- getHref() seems to 'hardcode' paths i.e. "/consumers/", is
there any way to get these values from the annotations?
Summary of IRC convo, we're sticking with this for now, zeus is still noodling on it.
I like the use of reflection in CandlepinSerializer very nice :D
can you add a link to the source for jackson's
beanserializerFactory in your CandlepinSerializerFactory?
Will do!
- SerializerProvider looks ok except is has an _serializerFactory
and _config. Is those jackson variables? If so, we'll need to get checkstyle to ignore this file somehow
Checkstyle wasn't griping, possibly because we don't actually declare them. (they are from Jackson parent class)
I like it so far, my biggest beef is with the Href() methods explicitly listing urls in them vs using some sort of annotations.
jesus
Thanks for checking it over, we'll see if we can come up with something better for that href.
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 | +---------------------------------------------+
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxsAAsACgkQvJZ57YntiYPNiwCdFME/ms/+mbgsN4yK3ROCVo5b sLAAoMpu1xSU33+SEh6haYHi1zViFM+A =WqkC -----END PGP SIGNATURE-----
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?
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?
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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.
Perhaps consumer.id needs to go away?
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?
I do like the idea of the internal/external keys. am I the only one? -- bk
On Tue, Aug 24, 2010 at 4:03 PM, Bryan Kearney bkearney@redhat.com wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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.
-----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@redhat.com wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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@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 | +---------------------------------------------+
On Tue, 24 Aug 2010, 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@redhat.com wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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}
This is a good point. If we are doing the HATEOAS thing then uuid vs id vs key or whatever shouldn't really matter. The href is what is important.
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@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----- _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
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 Kearneybkearney@redhat.com wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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
On Tue, Aug 24, 2010 at 8:20 PM, Bryan Kearney bkearney@redhat.com wrote:
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 Kearneybkearney@redhat.com wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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.
I do not see the point in including an ID that's useless to the caller, particularly in this 'minimal' serialized form, but if it looks ok to you guys it's fine with me. (makes life easier :))
So lets say we implement a top level link hierarchy, what would this look like? Something as simple as:
consumers -> "/consumers" pools -> "/pools" owners -> "/owners" entitlements -> "/entitlements"
Do we also need to include info about the supported query parameters? This is probably more in the realm of a WADL, problem for another day?
Does this list need to get filtered depending on whether or not your current role has access to those calls? For instance, only a super admin can list the owners.
Cheers,
Devan
On Wed, Aug 25, 2010 at 9:08 AM, Devan Goodwin dgoodwin@rm-rf.ca wrote:
On Tue, Aug 24, 2010 at 8:20 PM, Bryan Kearney bkearney@redhat.com wrote:
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 Kearneybkearney@redhat.com wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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.
I do not see the point in including an ID that's useless to the caller, particularly in this 'minimal' serialized form, but if it looks ok to you guys it's fine with me. (makes life easier :))
-- Devan Goodwin dgoodwin@rm-rf.ca http://rm-rf.ca
On Wed, 25 Aug 2010, Devan Goodwin wrote:
So lets say we implement a top level link hierarchy, what would this look like? Something as simple as:
consumers -> "/consumers" pools -> "/pools" owners -> "/owners" entitlements -> "/entitlements"
Do we also need to include info about the supported query parameters? This is probably more in the realm of a WADL, problem for another day?
I would think that any parameters needed would just be in the href, but for other optional ones - I really have no idea. I would think that if we don't have an immediate use case, we should punt on that for now.
Does this list need to get filtered depending on whether or not your current role has access to those calls? For instance, only a super admin can list the owners.
Yeah this seems like the right thing to do. IMHO it is poor user design to present options that are not available.
Cheers,
Devan
On Wed, Aug 25, 2010 at 9:08 AM, Devan Goodwin dgoodwin@rm-rf.ca wrote:
On Tue, Aug 24, 2010 at 8:20 PM, Bryan Kearney bkearney@redhat.com wrote:
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 Kearneybkearney@redhat.com wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote: > > On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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.
I do not see the point in including an ID that's useless to the caller, particularly in this 'minimal' serialized form, but if it looks ok to you guys it's fine with me. (makes life easier :))
-- Devan Goodwin dgoodwin@rm-rf.ca http://rm-rf.ca
-- Devan Goodwin dgoodwin@rm-rf.ca http://rm-rf.ca _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On Wed, Aug 25, 2010 at 1:10 PM, Justin Harris jharris@redhat.com wrote:
On Wed, 25 Aug 2010, Devan Goodwin wrote:
So lets say we implement a top level link hierarchy, what would this look like? Something as simple as:
consumers -> "/consumers" pools -> "/pools" owners -> "/owners" entitlements -> "/entitlements"
Do we also need to include info about the supported query parameters? This is probably more in the realm of a WADL, problem for another day?
I would think that any parameters needed would just be in the href, but for other optional ones - I really have no idea. I would think that if we don't have an immediate use case, we should punt on that for now.
Well there are several optional params you can send with a GET /pools which clients will have to just assume. I think WADL is the solution for this though.
Does this list need to get filtered depending on whether or not your current role has access to those calls? For instance, only a super admin can list the owners.
Yeah this seems like the right thing to do. IMHO it is poor user design to present options that are not available.
Ok thought so, I will try to make it happen.
On 08/25/2010 12:15 PM, Devan Goodwin wrote:
On Wed, Aug 25, 2010 at 1:10 PM, Justin Harrisjharris@redhat.com wrote:
On Wed, 25 Aug 2010, Devan Goodwin wrote:
So lets say we implement a top level link hierarchy, what would this look like? Something as simple as:
consumers -> "/consumers" pools -> "/pools" owners -> "/owners" entitlements -> "/entitlements"
I think yes.. I would be this sime. I would check in with the deltacloud guys, see what their top level is.
-- bk
On Wed, Aug 25, 2010 at 1:15 PM, Devan Goodwin dgoodwin@rm-rf.ca wrote:
Does this list need to get filtered depending on whether or not your current role has access to those calls? For instance, only a super admin can list the owners.
Yeah this seems like the right thing to do. IMHO it is poor user design to present options that are not available.
Ok thought so, I will try to make it happen.
So how badly do we want this list of links filtered based on permissions?
I'm seeing a problem with REST and our model here. Let's say my top level links comes back with /pools, and I'm authenticating as a consumer.
Clearly I can GET /pools and view the pools I have access too. Now with REST, it's implicit that you know the methods you can run on a resource right? But in this case, a consumer cannot POST to /pools, whereas a super admin could. Am I correct that this information is not represented anywhere in HATEOAS, we just have to give back the links and accept that some operations will fail on them if you try, whereas others will succeed. (similarly for some that are not implemented)
With this in mind, I got to thinking it may not be worth filtering the top level links because the security on the operations beneath them are not going to be accurately represented anyhow.
Even for the top level, filtering will be somewhat difficult. In the root resource, we'll need to do *heavy* introspection on the Resource classes to determine what links should appear. Basically we have to hard code a list of the Resource classes, examine the @Path on those to extract just the name of the objects. If we now want to check the security, we have to run through that class and find a method with @GET and no @Path, possibly with some other checks as well. (quite messy) The alternative would be just hard coding the security logic in the root resource that builds the links, but then it's duplicated with the real security on the method in the Resource class, and undoubtedly will get out of sync.
Thoughts?
Thanks,
Devan
On Fri, 27 Aug 2010, Devan Goodwin wrote:
On Wed, Aug 25, 2010 at 1:15 PM, Devan Goodwin dgoodwin@rm-rf.ca wrote:
Does this list need to get filtered depending on whether or not your current role has access to those calls? For instance, only a super admin can list the owners.
Yeah this seems like the right thing to do. IMHO it is poor user design to present options that are not available.
Ok thought so, I will try to make it happen.
So how badly do we want this list of links filtered based on permissions?
I'm seeing a problem with REST and our model here. Let's say my top level links comes back with /pools, and I'm authenticating as a consumer.
Clearly I can GET /pools and view the pools I have access too. Now with REST, it's implicit that you know the methods you can run on a resource right? But in this case, a consumer cannot POST to /pools, whereas a super admin could. Am I correct that this information is not represented anywhere in HATEOAS, we just have to give back the links and accept that some operations will fail on them if you try, whereas others will succeed. (similarly for some that are not implemented)
With this in mind, I got to thinking it may not be worth filtering the top level links because the security on the operations beneath them are not going to be accurately represented anyhow.
Even for the top level, filtering will be somewhat difficult. In the root resource, we'll need to do *heavy* introspection on the Resource classes to determine what links should appear. Basically we have to hard code a list of the Resource classes, examine the @Path on those to extract just the name of the objects. If we now want to check the security, we have to run through that class and find a method with @GET and no @Path, possibly with some other checks as well. (quite messy) The alternative would be just hard coding the security logic in the root resource that builds the links, but then it's duplicated with the real security on the method in the Resource class, and undoubtedly will get out of sync.
Thoughts?
Yeah my previous comment was mainly geared toward your /pools example, where we are already filtering what the user can see, so we just return those URLs. I think that in a perfect world you would always see what you can do, but my gut feeling is that we are doing a lot more with roles/permissions that the average rest interface. I totally agree it is pretty crazy to try and do a bunch of magic for the "/" level - and worst case scenario the existing security stuff kicks in on certain actions.
I'm honestly not sure how are current security setup jives with what is needed/proposed for kalpana, so it might be the case that this stuff will need to be revisited sooner or later - in which case we can try to integrate it more with HATEOAS when/if that happens.
Thanks,
Devan
-- Devan Goodwin dgoodwin@rm-rf.ca http://rm-rf.ca
Having some troubles seeing HATEOAS through to it's proper completion, I really cannot see how to properly model nested resources so you discover the links to them, rather than assume them.
A list of the nested resources our Ruby library currently deals with:
/owners/id/users /owners/id/subscriptions /consumers/uuid/entitlements /consumers/uuid/certificates /consumers/uuid/certificates/serials /consumers/uuid/atom /products/id/content /products/id/certificates /entitlements/product/productid (used for regenerating entitlement certs)
For starters, note that there remains a circular dependency problem with a lot of objects, such as consumer's entitlements. Ideally I would like serialization of a consumer to include the array of their entitlements (in HATEOAS id+href form). This is fine in this case, but not during something like an export, which cannot do HATEOAS serialization and needs to write the entire object. (I'm working on a solution for this using Jackson views but I'm not sure it will pan out)
So how *would* I know where to look for a consumers entitlements? Am I correct in assuming that ideally, consumer serialization would somehow include a link to the entitlements collection itself? Needless to say this is going to be tricky and our serialization is getting more and more complicated, but it may be possible.
i.e.
GET /consumers/{uuid} -> {'entitlements' => '/consumers/{uuid}/entitlements')
GET /consumer/{uuid}/entitlements -> [{'id' => 1, 'href' => '/entitlements/{id}, ...]
Any thoughts?
Cheers,
Devan
On Fri, Aug 27, 2010 at 11:39 AM, Justin Harris jharris@redhat.com wrote:
On Fri, 27 Aug 2010, Devan Goodwin wrote:
On Wed, Aug 25, 2010 at 1:15 PM, Devan Goodwin dgoodwin@rm-rf.ca wrote:
Does this list need to get filtered depending on whether or not your current role has access to those calls? For instance, only a super admin can list the owners.
Yeah this seems like the right thing to do. IMHO it is poor user design to present options that are not available.
Ok thought so, I will try to make it happen.
So how badly do we want this list of links filtered based on permissions?
I'm seeing a problem with REST and our model here. Let's say my top level links comes back with /pools, and I'm authenticating as a consumer.
Clearly I can GET /pools and view the pools I have access too. Now with REST, it's implicit that you know the methods you can run on a resource right? But in this case, a consumer cannot POST to /pools, whereas a super admin could. Am I correct that this information is not represented anywhere in HATEOAS, we just have to give back the links and accept that some operations will fail on them if you try, whereas others will succeed. (similarly for some that are not implemented)
With this in mind, I got to thinking it may not be worth filtering the top level links because the security on the operations beneath them are not going to be accurately represented anyhow.
Even for the top level, filtering will be somewhat difficult. In the root resource, we'll need to do *heavy* introspection on the Resource classes to determine what links should appear. Basically we have to hard code a list of the Resource classes, examine the @Path on those to extract just the name of the objects. If we now want to check the security, we have to run through that class and find a method with @GET and no @Path, possibly with some other checks as well. (quite messy) The alternative would be just hard coding the security logic in the root resource that builds the links, but then it's duplicated with the real security on the method in the Resource class, and undoubtedly will get out of sync.
Thoughts?
Yeah my previous comment was mainly geared toward your /pools example, where we are already filtering what the user can see, so we just return those URLs. I think that in a perfect world you would always see what you can do, but my gut feeling is that we are doing a lot more with roles/permissions that the average rest interface. I totally agree it is pretty crazy to try and do a bunch of magic for the "/" level - and worst case scenario the existing security stuff kicks in on certain actions.
I'm honestly not sure how are current security setup jives with what is needed/proposed for kalpana, so it might be the case that this stuff will need to be revisited sooner or later - in which case we can try to integrate it more with HATEOAS when/if that happens.
Thanks,
Devan
-- Devan Goodwin dgoodwin@rm-rf.ca http://rm-rf.ca
On 08/30/2010 01:15 PM, Devan Goodwin wrote:
Having some troubles seeing HATEOAS through to it's proper completion, I really cannot see how to properly model nested resources so you discover the links to them, rather than assume them.
A list of the nested resources our Ruby library currently deals with:
/owners/id/users /owners/id/subscriptions /consumers/uuid/entitlements /consumers/uuid/certificates /consumers/uuid/certificates/serials /consumers/uuid/atom /products/id/content /products/id/certificates /entitlements/product/productid (used for regenerating entitlement certs)
For starters, note that there remains a circular dependency problem with a lot of objects, such as consumer's entitlements. Ideally I would like serialization of a consumer to include the array of their entitlements (in HATEOAS id+href form). This is fine in this case, but not during something like an export, which cannot do HATEOAS serialization and needs to write the entire object. (I'm working on a solution for this using Jackson views but I'm not sure it will pan out)
So how *would* I know where to look for a consumers entitlements? Am I correct in assuming that ideally, consumer serialization would somehow include a link to the entitlements collection itself? Needless to say this is going to be tricky and our serialization is getting more and more complicated, but it may be possible.
i.e.
GET /consumers/{uuid} -> {'entitlements' => '/consumers/{uuid}/entitlements')
GET /consumer/{uuid}/entitlements -> [{'id' => 1, 'href' => '/entitlements/{id}, ...]
Any thoughts?
I was assuming the latter.. but I could go with either. To be honest, if we get the href in each object and it's parent then I would be fine calling it good for a first cut.
-- bk
Ok I'm leaving this be for now. What we have in the hateoas2 branch:
- Most of our core objects have an href. (might need to be added to a couple more) - Top level links are provided if you GET the root of the webapp. - Object relationships will be serialized in HATEOAS form. (just "id" and "href") - Collections will be serialized in HATEOAS form. (I still worry about performance hit but we'll see) - Unit tests + rspec passing.
TODO before a merge:
- Update RHSM for new link changes, mostly around collections. - Cucumber test fixes.
Maybe TODO:
- Stop assuming paths in Ruby and Python libraries. - Nested collection URLs are not discoverable or even consistently implemented. Bit of work here I suspect, and not entirely sure how to solve. - Add a lazily loaded proxy Product object so we could serialize the pool.product relationship as a link. (same for Subscriptions)
Cheers,
Devan
On Mon, Aug 30, 2010 at 2:21 PM, Bryan Kearney bkearney@redhat.com wrote:
On 08/30/2010 01:15 PM, Devan Goodwin wrote:
Having some troubles seeing HATEOAS through to it's proper completion, I really cannot see how to properly model nested resources so you discover the links to them, rather than assume them.
A list of the nested resources our Ruby library currently deals with:
/owners/id/users /owners/id/subscriptions /consumers/uuid/entitlements /consumers/uuid/certificates /consumers/uuid/certificates/serials /consumers/uuid/atom /products/id/content /products/id/certificates /entitlements/product/productid (used for regenerating entitlement certs)
For starters, note that there remains a circular dependency problem with a lot of objects, such as consumer's entitlements. Ideally I would like serialization of a consumer to include the array of their entitlements (in HATEOAS id+href form). This is fine in this case, but not during something like an export, which cannot do HATEOAS serialization and needs to write the entire object. (I'm working on a solution for this using Jackson views but I'm not sure it will pan out)
So how *would* I know where to look for a consumers entitlements? Am I correct in assuming that ideally, consumer serialization would somehow include a link to the entitlements collection itself? Needless to say this is going to be tricky and our serialization is getting more and more complicated, but it may be possible.
i.e.
GET /consumers/{uuid} -> {'entitlements' => '/consumers/{uuid}/entitlements')
GET /consumer/{uuid}/entitlements -> [{'id' => 1, 'href' => '/entitlements/{id}, ...]
Any thoughts?
I was assuming the latter.. but I could go with either. To be honest, if we get the href in each object and it's parent then I would be fine calling it good for a first cut.
-- bk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/24/2010 03:03 PM, Bryan Kearney wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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.
Perhaps consumer.id needs to go away?
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?
I do like the idea of the internal/external keys. am I the only one? -- bk
I thikn we should keep the consumer.id around. Personally, I think it'll become a PITA with hibernate if we don't use id.
Also, I see no problem with being able to get to a consumer using both the dbid and the uuid.
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 | +---------------------------------------------+
On Tue, 24 Aug 2010, Bryan Kearney wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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.
Perhaps consumer.id needs to go away?
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?
I do like the idea of the internal/external keys. am I the only one?
I'm just not sure what having two separate keys buys us (besides confusion).
-- bk _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 08/24/2010 03:33 PM, Justin Harris wrote:
On Tue, 24 Aug 2010, Bryan Kearney wrote:
On 08/24/2010 09:49 AM, Devan Goodwin wrote:
On Wed, Aug 18, 2010 at 9:57 AM, Devan Goodwindgoodwin@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.
Perhaps consumer.id needs to go away?
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?
I do like the idea of the internal/external keys. am I the only one?
I'm just not sure what having two separate keys buys us (besides confusion).
The ability to mutate one of them (the external one)
-- bk
candlepin@lists.stg.fedorahosted.org
-
Adam Young -
Bryan Kearney -
Devan Goodwin -
James Bowes -
jesus rodriguez -
Justin Harris