RE: Supported operations per hydra:Class instance

Hi Eric,

On Friday, August 22, 2014 3:50 PM, Eric Brisco wrote:
> I will use the Hydra Console demo application (the Issue tracker) to
> describe my concern.
> 
> Here you can view an instance of the Issue class: http://www.markus-
> lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra
> /api-demo/issues/2#
> 
> If you click on the comments IRI, the dialog is knowledgable about the
> GET and POST operations. This is because "comments" is a hydra:Link
> instance; per instance of hydra:Link you may specify the supported
> operations on the associated IRI, and the demo application has done
> so.
> 
> Now GET the comments: http://www.markus-
> lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra
> /api-demo/issues/2/comments/#
> 
> On this screen we no longer know the supported operations on the
> comments. This is because the entity is an instance of the
> hydra:Collection class, and that class does not specify any supported
> operations (because there are no operations it can presume). It seems

That's correct. The reason for this is that I haven't attached any
operations to the generic Collection class.


> puzzling that, unlike the hydra:Link type, you cannot specify the
> supported operations per instance of a hydra:Class (noting that
> hydra:Collection is a subtype of hydra:Class). This means that

You can associate operations to classes exactly the same way. Have a look at
the Event API demo:

  http://bit.ly/hydra-console-event-api

I introduced a specialized EventCollection class there which has operations
attached to it. Consequently, that demo doesn't expose the problem you
described above.


> supported operations are tied to class definitions, rather than
> instances, and thus the only solution here is to subtype
> hydra:Collection merely to define supported operations.

They are always tied to instances or values of properties (hydra:Link). You
can also embed operations directly into instances by using the
hydra:operation property inline instead of resorting to
hydra:supportedOperation in an hydra:ApiDocumentation.


> Imagine that you were listing blog posts on a website with multiple
> authors, and only the author of a particular post was able to edit
> that post. In that scenario it is not possible to model the supported
> operations because the granularity must be per instance of the
> (hypothetical) Post class.

Do you want to serve different representations of a post for different
authenticated users as you normally do on websites? If so, you have two
options:

a) you include an operation directly into the representation if the post can
be deleted:

  {
      "@type": "BlogPost",
      ...
      "operation": {
          "@type": "EditAction",
          "method": "PUT",
          ...
      }
  }


b) you define a new class for editable blog posts and add that type
dynamically to the relevant representations:

  {
      "@type": [ "BlogPost", "EditableBlogPost" ],
      ...
  }


If you can't serve different representations for different users, basically
the only thing you can do is to associate the operation to the BlogPost
class and let return an error at runtime (403 Forbidden).


Btw. there's a W3C Community Group [1] working on Hydra. I'd like to invite
you to join the group. The steps to do so are outlined at

    http://www.hydra-cg.com/#community

(it's free and you don't have to work for a W3C member company)


Hope to welcome you soon on the group,
Markus


[1] http://www.w3.org/community/hydra


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 4 September 2014 10:31:07 UTC