Re: Modeling permissions with Hydra

I both agree and disagree with some of your arguments.

>Tomasz
>Good point. I accepted Markus' arguments before but what you write does 
>make sense. Common example of Hypermedia-driven API, often raised on this 
>list, is HTML+browser. All controls are included in the representation; ie. 
>there is no documentation.
Good point, but well, this approach is also known as world's best structured 
data shredder. That's why there is no crawler capable of doing anything else 
that HTTP GET as there is documentation and having hypermedia controls with 
actual content pollutes the content. Same thing with RDF - I personally 
acknowledge hypermedia controls embedded in my data as a pollution and I'm 
keen to get rid of then to a separated payload - this is my personal 
statement. Also, from ReST point of view client should send back the 
resource, but I'd argue whether hypermedia controls should be sent back as 
these usually are not the part of the resource from data point of view.

>Rayan
> I'm less and less sure that I see the use of having potential state
> transitions advertised anywhere *other* than in representations,
> except as a way of generating human-readable documentation. A Hydra
> client is always going to have to be ready to look for advertisements
> of possible state transitions in individual representations anyway; so
> what is the use of complicating client implementation by saying, "hey,
> here are some other places to look for possible state transitions"?
> Why not just leave it at "state transitions are advertised in
> representations, period"? What would be the drawbacks of dropping
> hydra:supportedOperation from the core vocabulary?
I'm quite advanced in a proof-of-concept business application that heavily 
utilizes API documentation to build user experience. I hope to have it 
presented in next few days/weeks.

>Tomasz
>If we were to align Hydra in similar fashion, all affordances could be 
>always included in the representation, which indeed removes part of the 
>burden from the client. What the ApiDocumentation would hold are all the 
>descriptions of supported types (shapes?). The only problem I see would be 
>with operations supported by (is that the proper expression?) specific 
>properties.

>Bottom line is, that last case may actually make it impossible to 
>completely move operations to individual resources. Even worse, you could 
>also include supported operations in representations of your API's terms 
>when dereferenced, which may or may not each redirect to a different 
>document depending on a particular setup.
Personally I see that both API documentation and hypermedia controls should 
be complementary to each other. Documentation is a good starting point for a 
client on where to start, what can be done, hypermedia should drive it's 
behaviour once in the middle of the communication chain.


Regards

Karol

Received on Saturday, 7 November 2015 11:22:10 UTC