（原谅问题标题;很难总结这个问题。）
在Facebook上，你有like件事。在推特上，你是follow个人。在GitHub上，您还follow人和star repos和gists。
所有这些情况都非常相似：这些连接是轻量级的，而不是真正的“资源”本身。例如。这三个API都没有公开这种连接的公共ID。
这提出了一个问题：公开用于创建/查询/删除这些连接的API的“最佳”（就REST而言）的方式是什么？
Facebook 执行[1]：
GET /:id/likes查询对象的喜欢（更确切地说，是喜欢该对象的用户）
POST /:id/likes喜欢某事（代表auth'ed用户;不需要req身体）
DELETE /:id/likes与某些内容不同（代表认证用户）
查询和创建有意义，但DELETE有点“不可靠”，因为您实际上并没有删除/:id/likes资源（喜欢该对象的用户数组）。 / p>
这种差异在另一个案例中显示[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 ，有趣的是，使用不同的风格主演 gists [4]：
GET /gists/:id/star查询您是否有主角
PUT /gists/:id/star主演要点
DELETE /gists/:id/star取消了要点
这样可以使用Facebook等资源资源保留主演行动，而不是用户资源。
GitHub没有公开曝光 gists'观星者，但可能就是这样。：
GET /gists/:id/stargazers查询曾主演过要点的用户虽然“观星者”确实是一个与“明星”不同的资源/名称，但名称相似且明显相关，并且它们都在同一资源上。
我能想到的唯一缺点就是命名资源。 star之类的内容有效，但follow或like等行为比较棘手。
（并不打算将Twitter API作为一个例子，因为它几乎不是RESTful。）
显然没有完美的RESTful API用于创建/查询/删除不合适资源的内容，但还有其他优点/缺点我没有看到，或者其他样式需要考虑？
谢谢！
答案 0 :(得分：1)
我喜欢/me/likes/:id风格的一件事是喜欢做喜欢单独的，可寻址的资源 - 例如他们有个人ID（恰好与我喜欢的东西相同）。
GitHub的 repo API很好地用于创建/查询/删除＆＃34; star＆＃34;与回购的关联，但是提取所有＆＃34; star＆＃34;之间存在差异。给定仓库的连接。
也许可以通过更改解决这些连接的方式来解决差异：而不是仅仅依赖于对象ID，也可以使用（auth＆＃39; ed）用户ID。 E.g：
GET /:owner/:repo/stargazers查询已为此回购主演的所有用户
GET /:owner/:repo/stargazers/:id来查询用户:id是否有回购加星标 - 这可以是通过指定me来验证用户！
PUT /:owner/:repo/stargazers/me为回购邮件加注星标 - 这只适用于授权用户
DELETE /:owner/:repo/stargazers/me取消回购 - 同上
现在所有资源/操作都在一起，操作是一致的，命名很容易。
编辑：此方法的另一个好处是，您可以轻松有效地查询其他用户是否喜欢/跟踪/加注对象。
修改但缺点是资源在技术上不再正确 - GET .../stargazers会返回用户的列表，但是{{ 1}}返回连接，而不是用户。哦，好吗？
[再次修改以支持在GET .../stargazers/:id传递me。]
答案 1 :(得分：0)
我认为
DELETE /：id /喜欢不同的东西（代表auth'ed用户）
是有道理的，因为like会有一个like对象的id和你的用户id的复合键，所以当你的身份验证登录已经告诉你是谁，你甚至没有权限时，指定一个id就是多余的无论如何，删除其他用户的喜欢。
明确指定（如Aseem Kishore建议）
DELETE /：id / likes / me
......可能会更清楚一点。