Re: Modeling permissions with Hydra

Am 04.11.2015 12:56 schrieb Asbjørn Ulsberg <asbjorn@ulsberg.no>:
>
> 2015-11-04 11:31 GMT+01:00 Tomasz Pluskiewicz <tomasz@t-code.pl>: 
>
> >> 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. 
>
> Can you please point me to this discussion? 

There was no formal decision or call for consensus about this, please correct me.

My view is: the spec says nothing about precedence or addition, it still must be clarified. My expectation would be: if the api documentation is the only source of supported operations, then clients may take this as a hint that all supported operations are available. It may use OPTIONS to check availability and it should handle status codes and hydra:Error to learn more about possible problems and their solution.

If the response contains operations, then the client should take this as a hint that only the inline operations are suitable in the current resource state and it should handle status and :Error to resolve possible problems.

I fail to see why it would be useful that the api documentation leaves out some operations and the response adds them at runtime.

Inline operations are a bit controversial, some consider them pollution of a pure RDF response and argue for separation of concerns. I think that happens only as long as your API is CRUD by nature and the only state change is "logged in or not". If the response of your API needs to drive application state, then the feeling of pollution goes away quite naturally ;-)

Best,
Dietrich