HATEOAS Patch

Bryan Kearney bkearney at redhat.com
Fri Aug 20 20:20:10 UTC 2010


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






More information about the candlepin mailing list