Re: Modeling permissions with Hydra

I agree. Being able to tell the client that an operation is unavailable 
and a reason is very practical. For example if I wanted to gray-out a 
button and display a tooltip informing the user why it cannot be clicked.

Do see this article for some inspiration:

http://apihandyman.io/hypermedia-api-maturity-model-part-ii-the-missing-links/

Best,
Tom

On 2016-02-15 13:28, Asbjørn Ulsberg wrote:
> 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?
>

Received on Monday, 15 February 2016 19:58:27 UTC