Re: Accept on GET and access control - ISSUE-93

hello henry.

On 2014-01-29, 16:19 , "Henry Story" <henry.story@bblfish.net> wrote:
>But it is true that it does not address Erik Wilde's issue about it being
>very likely that most requests will never
>need this information and that it is expensive to calculate, so that
>perhaps making the information obligatory
>in GET or HEAD is likely to lead to bad practices.

don't take this as an official statement of any kind (;-), but i am fairly
certain that if we were to implement LDP on top of our CMS, and we would
be forced to always serve this information, we would be very very tempted
to always say that everything is allowed, and rely on the the fact that
client have to deal with the actual runtime behavior anyway, so nothing
would ever actually go wrong.

for us, it would be a UX trade-off. having horribly long response times
because of complex and layered access policies would impact UX much more
than trying to actually access something, and then find out that its
access rights changed. both things are not great, which is why we have
come up with something in the middle.

for our web API, we are using link hints
http://tools.ietf.org/html/draft-wilde-link-desc, and the idea is that
clients can request a resource's "service surface" explicitly, if they
need it. that allows clients to be much more selective when it comes to
determining what kind of interactions a resource supports (in our case,
this link description also includes information about URI templates and
their values), plus it turns this interaction information into a resource
of its own (which is one of the problem of OPTIONS responses: they are not
cacheable).

cheers,

dret.

Received on Wednesday, 29 January 2014 16:15:47 UTC