HATEOAS Patch

Adam Young ayoung at redhat.com
Fri Aug 20 13:43:29 UTC 2010


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?





More information about the candlepin mailing list