抱歉标题有些拗口，难以概括这个问题。
在Facebook上，您可以点赞。在Twitter上，您可以关注人。在GitHub上，您也可以关注人并收藏存储库和代码片段。
所有这些情况都非常相似：这些连接都是轻量级的，本身不是“资源”。例如，这三个API都不公开此类连接的公共ID。
这引出了一个问题：在REST方面，暴露用于创建/查询/删除这些连接的API的“最佳”方式是什么？
Facebook提供以下API接口1:
GET /:id/likes用于查询对象的点赞数量（更准确地说，是喜欢该对象的用户）POST /:id/likes用于点赞某个内容（代表授权用户进行操作；不需要请求正文）DELETE /:id/likes用于取消点赞某个内容（代表授权用户进行操作）
查询和创建操作很合理，但DELETE操作有些“不符合RESTful”原则，因为您实际上并没有删除/:id/likes资源（一个喜欢该对象的用户数组）。
这种差异在另一种情况下也会出现2:
GET /me/likes/:id用于查询您是否喜欢某个内容
因此，查询您的连接是查询一个完全不同的资源，而不是创建或删除它。
GitHub 倾向于使用 /me/likes/:id 风格来关注用户和标记 repos [3]:
（请注意，GitHub 的 /user 表示已认证的用户，就像 Facebook 的 /me 一样。）
GET /user/starred/:owner/:repo用于查询您是否已收藏存储库（返回 204 或 404，无论如何都没有正文）PUT /user/starred/:owner/:repo用于将存储库标记为收藏（请求中不需要正文）DELETE /user/starred/:owner/:repo用于取消对存储库的标记
这样做更加一致，但不幸的是，这将单个“星标”与群组分开：
GET /repos/:owner/:repo/stargazers用于查询已标记存储库的用户
GitHub有趣的是，对于收藏代码片段 [4]，使用了不同的样式：
GET /gists/:id/star用于查询您是否已经收藏了一个代码片段PUT /gists/:id/star用于收藏一个代码片段DELETE /gists/:id/star用于取消收藏一个代码片段
这保持了收藏行为与代码片段资源的关联，类似于Facebook，而不是用户资源。
GitHub没有公开展示代码片段的收藏者，但可能会有例如：
GET /gists/:id/stargazers查询收藏了一个代码片段的用户
虽然“stargazers”确实是一个不同的资源/名称而不是“star”，但名称相似且明显相关，并且它们都在同一资源上。
我能想到的唯一缺点是给资源命名。像star 这样的名称可以使用，但像 follow 或 like 这样的操作就比较棘手了。
由于Twitter API几乎不是RESTful的，因此我不打算将其作为示例。
显然，没有完全符合RESTful标准的API用于创建/查询/删除不是适当资源的事物，但我是否忽略了其他优缺点或需要考虑的其他风格？
谢谢！