Re: Modeling permissions with Hydra

I agree

No RDF statement overriding is present here. API Documentation describes an API, hypermedia controls describes the transitions. Indeed, both are expressed via RDF statements as (in general) there is no other reasonable way, but I wouldn’t talk about RDF statement overriding, but overriding behaviour described with these statements. Actually, this is already the case – API Documentation may state that an operation exists, but still client may end up with HTTP 403 (OK, this is not RDF statement) which changes the behaviour described in the documentation.

Regards

Karol

From: Dietrich Schulten 
Sent: Friday, November 6, 2015 10:31 AM
To: Asbjørn Ulsberg 
Cc: Tomasz Pluskiewicz ; Markus Lanthaler ; Hydra 
Subject: Re: Modeling permissions with Hydra

One might also argue that supportedProperties are there for documentation only, too: the ApiDocumentation says if a property should always be present or not - if the property is *really* defined for a particular instance and its value is decided by the representation. 

The situation is similar for supportedOperations, as I see it. Maybe one could use the required flag to express if an operation is always there or optional. Then the ApiDoc is for documentation, but it doesn't define an actual operation on instances - just like supportedProperties do not define triples on response instances, but only describe them.

Am 05.11.2015 05:38 schrieb Dietrich Schulten <ds@escalon.de>:


  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