- From: Karol Szczepański <karol.szczepanski@gmail.com>
- Date: Fri, 27 Nov 2015 20:53:40 +0100
- To: <public-hydra@w3.org>, "Thomas Hoppe" <thomas.hoppe@n-fuse.de>
Hi >> GET/buildings/main/ - retrieves the collection members of the "main" >> building >> GET /buildings/main/lobby - retrieves the "lobby" room >> (POST/buildings/main/ - create a new "Room" resource in the "main" >> building) >> >> we wouldn't have a way to access the collection's metadata (the >> building's "address" for example). >>So for that reason it seems we do need some intermediate level between the >>container and the contentish resource. >No one prevents you from using the "other dimensions" of an IRI such as the >query string to differentiate here. >For example to interact with the meta data part of a resource, you can just >have a ?meta in the URL. >That's still restful as a different IRI can point to a completely different >resource, >even if the difference is only in the query string. I'd disagree - it needs a client to know something extra. I'd go with something that's a common ground for both client and server - HTTP feature. Meaybe a verb (i.e. OPTIONS - only drawback is that responses are not cacheable), a specific acceptable content type or a request Link header with some specific rel, i.e. meta. I think an extra query string parameter is far from what ReST presents. Optionally, you could indeed have that query string parameter, but this should be additionally described with some hypermedia controls achieveing both ReST and HATOAS simultanously. In general, we've touched a matter of having data and meta-data/hypermedia controls mixed in several discussions now. I personally prefer to push that out of the data i.e. to headers or separate request or separate RDF graph. I believe Hydra spec is silent in this area. Best Karol Szczepański
Received on Friday, 27 November 2015 19:54:11 UTC