Re: [Specifications] Adding already existing resources as collection members

> On which resource do you plan to advertise such linking action? The video (eg. /videos/144522067) or that collection view (eg. /videos/144522067/likes)?

It doesn't really matter. Like we discussed at the call, I think it's up to the server to advertise one or both. And side effects are outside of the scope of hypermedia controls.

So, if you `DELETE /users/elfpavlik/likes/144522067 ` (or UNLINK) it does not matter that the appropriate triple is removed from both sides. Remember we're not necessarily talking about RDF at all. Deleting could mean removing a single row from a linking table in SQL. Both representations get affected automatically.

That said, I think we should be careful with comparing to LDP. That spec is targeted at manipulating RDF. Hydra is a vocabulary for defining Hypermedia, which is storage format agnostic. Coincidentally we use RDF for resource representations.

> I believe these semantic operations should be defined in the spec either with native Hydra namespace based terms or explicit terms reused from other vocabularies.

There are operations which will commonly occur in various APIs as much as link relations. I'd encourage reuse where possible but API-specific vocabularies are necessary. And we're not discouraging API-specific links either, are we? 

But, if I follow the logic here, these semantic operations should only define why the operations should be invoked, not why. The mechanics should be completely in the scope of the controls. That way a client can look for an operation `ex:like_video`. But whether it will do a `PUT` or `POST` or a `LINK` request is discovered at runtime and can change over time...

-- 
GitHub Notification of comment by tpluscode
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/134#issuecomment-335016724 using your GitHub account

Received on Sunday, 8 October 2017 16:06:10 UTC