抱歉标题有些拗口,难以概括这个问题。
在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用于创建/查询/删除不是适当资源的事物,但我是否忽略了其他优缺点或需要考虑的其他风格?
谢谢!