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