- From: Tomek Pluskiewicz <tomasz@pluskiewicz.pl>
- Date: Wed, 11 Jun 2014 20:38:51 +0200
- To: public-hydra@w3.org
Hi 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? Regards, Tom
Received on Thursday, 12 June 2014 09:30:26 UTC