- From: Thomas Hoppe <thomas.hoppe@n-fuse.de>
- Date: Wed, 23 Apr 2014 08:33:08 +0200
- To: public-hydra@w3.org
Hi, I didn't meant to say that there is no alternative, of course there are -- You could just introduce your own operation just to name one. Seeing hydra as a vocabulary to describe APIs it is just annoying to have 3 of four basic REST operations and one is missing. However, If we are about to remove them completely (what I also voted for earlier), this issue is resolved anyway. The authorization concern is not only for read requests. I will share my solution for this to the list once it is somewhat presentable anyway. Greets, Thomas On 04/21/2014 10:19 AM, Ruben Verborgh wrote: > Hi Thomas, > >> I want againt stress that existence of such an operation >> is required if you want to integrate the hydra based API >> description with a solution to define authorization constraints (who can read what in an API?). > That's not true; “RetrieveResourceOperation” is not the only possible solution for authorization. > > What I propose is that you create an issue "authorization for read requests" > and that we have a look at different options. > I don't think it makes sense to accept RetrieveResourceOperation > just because it is one solution to another problem. > >> I also don't understand why only resource modification is in focus of >> hydra as you say - considering collection searching, filtering and paging this >> is not true. > They are in Hydra scope, but they are different things. > Reading stuff is changing application state, > writing stuff is changing resource state. See ISSUE-44. > > Best, > > Ruben
Received on Wednesday, 23 April 2014 06:33:38 UTC