Re: Modeling permissions with Hydra

November 4 2015 10:52 AM, "Asbjørn Ulsberg" <asbjorn@ulsberg.no> wrote: 
> 2015-11-01 16:25 GMT+01:00 Markus Lanthaler <markus.lanthaler@gmx.net>:
> 
>> One approach that you haven't considered is given clients all the options
>> but telling them at run time which aren't possible. In other words, responding
>> with a 401 Unauthorized. I do that in the demo APIs for instance when users
>> aren't authenticated.
> 
> How about the combination of a static hydra:ApiDocumentation and
> inline hydra:operation? Would the latter override the former? Is this
> described anywhere?
> 

This has been discussed in length before.

AFAIR, both descriptions are intended to be combined. The is no overriding

>>> seems relevant is cacheability. Is it better to have API documentation
>>> that varies infrequently, or specific resource representations that
>>> change infrequently?
>> 
>> For me personally, it feels more natural to have a ApiDocumentation that
>> can be cached for a long time than optimizing for resource cacheability.
> 
> I agree. And for the most part, a static ApiDocumentation will
> describe the API truthfully. And in that case, the resources will be
> more static as well, since they need to contain less information about
> what they are, which operations they support, etc. But being able to
> override the ApiDocumentation with inline operations and such, would
> be neat; ref. my question above.
> 

But in light of the above, you would have to use 401 status codes. 
As an alternative, you could have client-side rules to be executed on resources to determine whether a particular operation is allowed.

> --
> Asbjørn Ulsberg -=|=- asbjorn@ulsberg.no
> «He's a loathsome offensive brute, yet I can't look away»

Received on Wednesday, 4 November 2015 10:32:37 UTC