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

Re: Modeling permissions with Hydra

From: Asbjørn Ulsberg <asbjorn@ulsberg.no>
Date: Wed, 4 Nov 2015 10:51:09 +0100
Message-ID: <CAEdRHi7vKTELfmOfREB4JLZQ0F1dKWSFuyH+Z34aws-mbQr8rg@mail.gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Cc: Hydra <public-hydra@w3.org>
2015-11-01 16:25 GMT+01:00 Markus Lanthaler <markus.lanthaler@gmx.net>:

> One approach that you haven't considered is given clients all the options
> but telling them at run time which aren't possible. In other words, responding
> with a 401 Unauthorized. I do that in the demo APIs for instance when users
> aren't authenticated.

How about the combination of a static hydra:ApiDocumentation and
inline hydra:operation? Would the latter override the former? Is this
described anywhere?

>> seems relevant is cacheability. Is it better to have API documentation
>> that varies infrequently, or specific resource representations that
>> change infrequently?
>
> For me personally, it feels more natural to have a ApiDocumentation that
> can be cached for a long time than optimizing for resource cacheability.

I agree. And for the most part, a static ApiDocumentation will
describe the API truthfully. And in that case, the resources will be
more static as well, since they need to contain less information about
what they are, which operations they support, etc. But being able to
override the ApiDocumentation with inline operations and such, would
be neat; ref. my question above.

-- 
Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»
Received on Wednesday, 4 November 2015 09:51:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 4 November 2015 09:51:39 UTC