- From: Karol Szczepański via GitHub <sysbot+gh@w3.org>
- Date: Sun, 08 Oct 2017 18:23:29 +0000
- To: public-hydra-logs@w3.org
> Please keep in mind that POST != create. From the spec
I know. The closest is PUT, but it requires quite a knowledge from the client (URL).
>>hierarchy of resources expressed with segments in the resource's URL may imply that the putted >>resource will be added to the collection
>Sorry to say, that is completely out of place. URL structures should imply nothing. It's just an identifier.
In our cases - that's true. There are specs that indeed a URL hierarchy actually matters.
>>hydra:Operation doesn't provide a way to specify hydra:IriTemplate
>So maybe let's work on that. Is there a reason why it shouldn't?
Agreed - I strongly support templated operations. I tried to use what's available in the spec in my URSA server/client solution, but the outcome is not very "healthy".
>For example, if the client was to PUT /article/{title} that title variable could also be part of the >operation's parameters.
Not a very good example, as indeed title could vary in time causing the URL to change, but with a property _mapped_ as unique identifier, client could take an advantage of the templated operations.
This should be an extension to the core Hydra anyway - I don't see Hydra defining what a _unique identifier_ is. Implementations can rely on owl:inverseFunctionalProperty, but from the template point of view it should be just another parameter. Only difficulty I see is that currently the spec says the the Iri template parameter is of a given property from the server point of view (i.e. server maps this parameter to that property) - it doesn't imply that client should use value of that very property when creating Iris.
--
GitHub Notification of comment by alien-mcl
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/141#issuecomment-335027457 using your GitHub account
Received on Sunday, 8 October 2017 18:23:18 UTC