W3C home > Mailing lists > Public > public-hydra@w3.org > November 2015

RE: Modeling permissions with Hydra

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 5 Nov 2015 23:08:53 +0100
To: "'Hydra'" <public-hydra@w3.org>
Message-ID: <043801d11816$8fa2e6e0$aee8b4a0$@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.


> 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?


> 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 example.


--
Markus Lanthaler
@markuslanthaler
Received on Thursday, 5 November 2015 22:09:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 November 2015 22:09:24 UTC