W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

Discovering Hydra API by dereferencing

From: Tomasz Pluskiewicz <tomasz@t-code.pl>
Date: Wed, 9 Jul 2014 22:22:14 +0200
Message-ID: <CAAFOhSftoWqgsWF5bAqVAL6wDc8UUrB48-No8eEPdwvwp7978g@mail.gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Cc: "public-hydra@w3.org" <public-hydra@w3.org>
Hi Markus

On JSON-LD list you wrote:

Yeah, to really get every possible operation and link, you would need
to reference all of them. I'm still a bit on the fence about that
because it is extremely inefficient in most cases. I was thinking
about adding a statement to the spec that basically requires all links
and operations to be declared either in the ApiDocumentation or inline
so that there are only those two places for a client to look at. Of
course people can place information also directly in vocabularies but
then it wouldn't be guaranteed that those things are discovered
*unless* they are also referenced by a apiDocumentation HTTP Link
header.

I'm conerned about (object) properties, which are not links. They will
most likely make up for most of the resources. I guess it wouldn't be
wise to try to dereference each one of them to see whether they are
typed as hydra:Links. Or would it?

Hm, and you also consider an idea that Hydra clients should not
actually dereference classes but only the ApiDocumentation, declared
in HTTP header?

Lastly what has just occured to me is that the ApiDocumentation would
have to be dereferenced at every request, is that right? Due to its
dynamic nature.

Regards,
Tom
Received on Wednesday, 9 July 2014 20:23:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC