RE: Modeling permissions with Hydra

Am 05.11.2015 23:08 schrieb Markus Lanthaler <markus.lanthaler@gmx.net>:
>
> On Thursday, November 05, 2015 5:39 AM, Dietrich Schulten wrote: 
> > 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. 
>
> It is a result of how the underlying data model works. You can't "override" triples/arcs in the graph. 

That is not what I want to do. A hydra:Class has :supportedOperation triples. The representation of the class has :operation triples. No overriding necessary.

>
>
> > 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 
>
> Why *only* the inline operations? 

The goal is to express the absence or presence of hyperlinks, so that the hypertext can be the engine of application state. Absence means that an application state transition is not intended. 

It imust be clear of course that all these are hints. The server must be prepared to return forbidden.

>
>
> > 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. 
>
> Because in a lot of cases you have operations that work across all resources of a specific type plus a few that work only on some. Think of favoriting an item vs. deleting it for exampl

Ah, in your view *this* is how you achieve state-dependent transitions.
That approach has a drawback: the ApiDocumentation cannot be complete. Developers looking at the documentation to find their way through the API must also run the application and try out possible states. But wait before you answer...

I would have expected both affordances as supportedOperation in the ApiDocumentation, and then at runtime, if only favoriting is suitable, then favoriting is the only :operation triple. If both are suitable, two :operation triples would be there. This approach also has a drawback: the case where no operations are suitable is difficult to express.

How about a second type of supportedOperations which solves *both drawbacks*, something like hydra:stateDependentOperation(s)? The latter are really only for documentation, if they are suitable or not is decided by their presence in the response?

BTW is this the next point on the agenda, operations? I don't want to drift off and would rather continue with the agenda. 

Best regards,
Dietrich