HATEOAS Patch

Devan Goodwin dgoodwin at rm-rf.ca
Mon Aug 30 17:15:19 UTC 2010


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 at redhat.com> wrote:
>
>
> On Fri, 27 Aug 2010, Devan Goodwin wrote:
>
>> On Wed, Aug 25, 2010 at 1:15 PM, Devan Goodwin <dgoodwin at 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 at rm-rf.ca>
>> http://rm-rf.ca
>



-- 
Devan Goodwin <dgoodwin at rm-rf.ca>
http://rm-rf.ca



More information about the candlepin mailing list