Re: Modeling permissions with Hydra

2016-02-07 16:34 GMT+01:00 Markus Lanthaler <markus.lanthaler@gmx.net>:

> In any case, you need to tell the client somehow what operations
> are available. IMO Hydra provides enough flexibility in that regard.

IMHO it doesn't. :)

>> Yes, but that does only give you the power of adding properties and
>> behaviors to a resource; it doesn't allow you to remove anything.
>
> I'm still not convinced that "removing things" is the right approach.

Call it what you want, but having Hydra say "this operation is no
longer available" is something we should try hard to support.

>> Only discovering operations, properties, etc. inline will lead to
>> surprises and breaks.
>
> Can you please elaborate on the "surprises and breaks" that you have
> in mind?

I'm thinking about this from the perspective of writing a client. If
there's no generic Hydra client available (which realistically won't
be available in most languages for many years and even after that
won't be known to implementors for even longer), this client will have
to be implemented based on API documentation. When writing a client
like this, I at least find it easiest having all of the documentation
out of band.

Then, as I go on testing my client against the server, I discover
things that the documentation wasn't clear about. I slowly learn by
interacting with the server how it behaves and what I can expect from
it. I can't assume every detail about how to write my client to be
listed in the out of band documentation. But I need that documentation
to get started and get somewhere like 90% in the right direction. Then
the last 10% is realtime discovery, interaction and details that
simply can't be written in out of band documentation.

While I know that the ApiDocumentation isn't meant to be this kind of
static out of band documentation, I think it's going to be really hard
to convince implementors that it isn't. I also don't think it's worth
the cognitive dissonance to have it this way; the benefits from having
a dynamic ApiDocumentation that might be useless out of band is simply
too high, imho.

>> Yes, but with CSS, it's possible for one class to replace and remove
>> every property defined by another.
>
> Out of curiosity, how do you remove a property in CSS? AFAICT the
> only thing you can do is override it.

Yea, "remove" was inaccurate. What you do is set it back to its
default state, often "auto" or "none".

> Correct. A statement is either there or not. All you can do is add
> more statements which modify the meaning of the data.

Can we somehow state that a previously added statement is no longer
valid, then? That the resource in its current state no longer supports
a previously supported and announced operation?

-- 
Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»

Received on Monday, 15 February 2016 12:29:04 UTC