5

（请原谅问题标题；很难总结这个问题。）

在 Facebook 上，你like的东西。在推特上，你们follow。在 GitHub 上，您还有follow人员、star存储库和要点。

所有这些情况都非常相似：这些连接是轻量级的，而不是真正的“资源”本身。例如，这三个 API 都没有公开此类连接的公共 ID。

这就提出了一个问题：公开用于创建/查询/删除这些连接的 API 的“最佳”（就 REST 而言）方式是什么？

Facebook确实 [ 1 ]：

  • GET /:id/likes查询对象的喜好（更准确地说，是喜欢该对象的用户）

  • POST /:id/likes喜欢某事（代表经过身份验证的用户；不需要请求正文）

  • DELETE /:id/likes与某事不同（代表经过身份验证的用户）

查询和创建是有意义的，但DELETE有点“unRESTful”，因为您实际上并没有删除/:id/likes资源（喜欢该对象的用户数组）。

这种差异在另一种情况 [ 2 ] 中表现出来：

  • GET /me/likes/:id询问你是否喜欢某事

因此，查询您的连接是查询与创建或删除它完全不同的资源。

GitHub倾向于/me/likes/:id关注用户和主演repos [ 3 ] 的风格：

（请注意，GitHub/user代表经过身份验证的用户，如 Facebook 的/me。）

  • GET /user/starred/:owner/:repo用于查询你是否有一个 repo 加星标（返回 204 或 404，没有正文）

  • PUT /user/starred/:owner/:repo为 repo 加注星标（请求中不需要正文）

  • DELETE /user/starred/:owner/:repo取消标记回购

这更加一致，但不幸的是，这将单个“星”与组分开：

  • GET /repos/:owner/:repo/stargazers查询已为 repo 加注星标的用户

有趣的是，GitHub使用了不同的风格来给要点[ 4 ] 加注：

  • GET /gists/:id/star用于查询您是否有一个要点

  • PUT /gists/:id/star主演一个要点

  • DELETE /gists/:id/star取消要点

这将使用 gist 资源（如 Facebook）而不是用户资源来保持主演动作。

GitHub 没有公开公开gists 的观星者，但大概是这样的：

  • GET /gists/:id/stargazers查询已加注星标的用户

虽然“stargazers”确实是与“star”不同的资源/名称，但名称相似且明显相关，并且它们都在同一资源上。

我能想到的唯一缺点是命名资源。类似的东西star有效，但类似follow或的行为like更棘手。

（不必费心将 Twitter API 作为示例，因为它几乎不是 RESTful。）

显然没有完美的 RESTful API 可用于创建/查询/删除不合适的资源，但是还有其他我没有看到的优点/缺点，或者需要考虑其他样式吗？

谢谢！

4

2 回答 2

1

我喜欢这种/me/likes/:id风格的一件事是，点赞确实感觉像是单独的、可寻址的资源——例如，它们有单独的 ID（恰好与我喜欢的东西相同）。

GitHub 的repo API 很好地使用它来创建/查询/删除到 repos 的“star”连接，但是在获取给定 repo 的所有“star”连接时存在差异。

也许可以通过更改处理这些连接的方式来解决差异：不要仅依赖对象 ID，还可以使用（已验证的）用户 ID。例如：

  • GET /:owner/:repo/stargazers查询所有为此 repo 加注星标的用户

  • GET /:owner/:repo/stargazers/:id查询用户是否:id已为 repo 加注星标——这可以通过指定me!

  • PUT /:owner/:repo/stargazers/me为 repo 加注星标——这只适用于经过身份验证的用户

  • DELETE /:owner/:repo/stargazers/me取消标记回购 - 同上

现在所有资源/动作都在一起了，动作一致，命名也很容易。

编辑：这种方法的另一个好处是您可以轻松有效地查询其他用户是否也喜欢/关注/加注对象。

编辑：但缺点是资源在技术上不再正确-GET .../stargazers返回用户列表，但GET .../stargazers/:id返回连接，而不是用户。那好吧？

me[再次编辑以支持作为:id这里的传递。]

于 2012-12-01T09:02:34.260 回答
0

我认为

DELETE /:id/likes to different things（代表经过身份验证的用户）

是有道理的，因为 like 会有一个被喜欢的对象的 id 和您的用户 id 的复合键，所以当您的身份验证登录已经告诉您是谁时，指定一个 id 只是多余的，而且您甚至没有权限删除其他用户的反正喜欢。

明确指定这一点（如 Aseem Kishore 所建议），如

删除/：id/喜欢/我

...可能会更清楚一点。

于 2013-12-04T13:13:35.703 回答