Re: Modeling permissions with Hydra

November 9 2015 10:54 AM, "Asbjørn Ulsberg" <asbjorn@ulsberg.no> wrote: 
> 
>> The only problem I see would be with operations supported by (is that
>> the proper expression?) specific properties.
> 
> I'm not sure I understand what you mean with this, so please elaborate.
>

Like in the example from the docs:

{
  "@context": "http://www.w3.org/ns/hydra/context.jsonld",
  "@id": "http://api.example.com/doc/#comments",
  "@type": "Link",
  "title": "Comments",
  "description": "A link to comments with an operation to create a new comment.",
  "supportedOperation": [
  {
    "@type": "CreateResourceOperation",
    "title": "Creates a new comment",
    "method": "POST",
    "expects": "http://api.example.com/doc/#Comment",
    "returns": "http://api.example.com/doc/#Comment"
  }
}

It is possible to define operations supported by a property. You will only be able to define that as part of a supported class (or external description of a property actually), unless you're happy to move that and duplicate for every occurrence. 

For example, let's assume that each collection member has a list of tags, and it's possible to add them by posting to that collection. Would you to duplicate the operation for each collection member? With ApiDocumentation it's possible to define that "each occurrence of the tags collection supports the POST operation". An alternative would be to include such description along your resource, possibly in a separate graph as per Ruben's article. That however, may be viewed as "too RDF" and would require even more changes in Hydra, I think.

Having wrote this, reducing duplication may be the best practical justification of ApiDocumentation. For me personally at least.

So maybe we are actually looking for a way to exclude certain supported operations for specific resource? Such that it would be possible to declare that a given supported operation does not apply in specific cases.

Received on Monday, 9 November 2015 12:58:21 UTC