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