RE: Modeling permissions with Hydra

On 21 Jan 2016 at 09:43, Asbjørn Ulsberg wrote:
> 2015-11-26 11:40 GMT+01:00 Markus Lanthaler:
> 
>> I would say that an operation isn't available for all resources of that type, the
>> ApiDocumentation shouldn't say so. It's trivial to introduce an additional
>> (sub)class (BlogPost vs. EditableBlogPost) and attach to operation to that
>> class instead.. or attach the operation to the resource directly.
> 
> But the state of the resources and the availability of their
> operations is transient. There's n indefinite set of variables that
> affect which operations are available on a resource in its current
> state. Obvious ones are authorization and lifecycle, but then you can
> have a load of external and invisible factors, such as the state of
> modules the resource depends on.

Right. In any case, you need to tell the client somehow what operations are available. IMO Hydra provides enough flexibility in that regard.


[...]
>> A resource can have multiple classes, so you can combine them.
> 
> Yes, but that does only give you the power of adding properties and
> behaviors to a resource; it doesn't allow you to remove anything.

I'm still not convinced that "removing things" is the right approach.


>> Also, there always the option to simply list the operations inline if
>> listing them upfront becomes impractical.
> 
> I believe doing both is very valuable. Only discovering operations,
> properties, etc. inline will lead to surprises and breaks. Only
> implementing based on a naïve understanding that the ApiDocumentation
> is written in stone and that the resources described in it won't
> change will also lead to surprises and breaks. Combining the two in an
> elegant and intuitive way will lead to easy implementation based on
> the ApiDocumentation and flexible clients based on inline metadata.

Can you please elaborate on the "surprises and breaks" that you have in mind?


>>> ... dynamically changing the client will potentially break consumers
>>> of the client, especially if the client is statically typed.
>> 
>> If that breaks consumers of the client, they won't be able to deal with
>> inline operations either, right?
> 
> True; however you convey the metadata to the client, the client won't
> work well in a statically typed language if the client itself is 100%
> fluid and dynamic.
> 
>>> Yes, but to continue that analogy, it's not very common that the
>>> centrally referenced CSS changes dynamically based on the state of the
>>> resource.
>> 
>> Right, that's the reason why I'm not a big fan of doing that (but mention
>> that is possible). I find using different classes (like in CSS) much better.
> 
> Yes, but with CSS, it's possible for one class to replace and remove
> every property defined by another.

Out of curiosity, how do you remove a property in CSS? AFAICT the only thing you can do is override it.


> That is not possible with either
> Hydra (in its current form), nor RDF, as far as I'm aware of.

Correct. A statement is either there or not. All you can do is add more statements which modify the meaning of the data.


--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 7 February 2016 15:34:57 UTC