W3C home > Mailing lists > Public > public-hydra@w3.org > June 2014

Specifying operations for instances

From: Tomek Pluskiewicz <tomasz@pluskiewicz.pl>
Date: Wed, 11 Jun 2014 20:38:51 +0200
Message-ID: <CAAFOhScF2VHxT1oP81Kem3SY65+LdL7U4OT_yAr43K2ihGeqRg@mail.gmail.com>
To: public-hydra@w3.org

The Hydra documentation gives two way for informing the client about
available operations for a resource.

The first is to use the supportedOperations property on the Class
resource. This gives the client a general view on all possible
interaction with all resources of that type.
The other way is to use the operation property directly on an instance.

I'd like to know your opinion/guidelines about some details:

1. Let there be a class, which supports operations X and Y. Let there
be an instance of that class, whose representation has operation X
included directly in it's representation, but not operation Y. Should
the client in such case assume that operation Y is not allowed on the
that resource? Should the client even look at the Class's
supportedOperations if operations are included in the resource itself?

2. I'm not very much in favor of including the operations directly in
resource representation, because I think it makes for a messy or
patched up server side code IMHO. What do you think about using the
OPTIONS verb instead and in returning the operations in response. This
way every resource can have it's own set of available operations based
on for example it's state or the user's permissions and at the same
time the server side code keeps a clear separation of concerns. Would
you think that the benefits outweigh the costs of additional traffic?

Received on Thursday, 12 June 2014 09:30:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:53:59 UTC