为用户与其他实体交互构建 URL 的 RESTful 方式是什么？

Question

我试图找出构建用户与其他实体交互的 URL 的正确 RESTful 方法是什么？

例如，我有三个实体：users、posts和tags。

如何表示“用户喜欢帖子”、“用户关注标签”或“用户关注用户”。

这是我的想法，但我不确定这是否是正确的方法：

POST /user/:id/like/post/:id（用户喜欢帖子）

POST /user/:id/follow/user/:id（用户关注另一个用户）

看起来很语义化，但我不确定 POST 方法

Answer 1

公平警告：我也是 REST 的新手。

一些一般性评论摘自Leonard Richardson 和 Sam Ruby 的RESTful Web Services ：

• 使用复数作为资源名称
• 如果服务器控制资源的标识，则对资源名称使用 POST
• 如果客户端控制资源的标识，则对资源/:id 使用 PUT

将其应用于您的情况我可以看到以下资源

• /users : 用户列表
• /users/{id} : 特定用户
• /users/{id}/tags ：该特定用户使用的标签列表
• /users/{id}/posts ：该特定用户喜欢的帖子列表
• /users/{id}/follows ：该特定用户关注的用户列表

要将帖子添加到用户喜欢的帖子中，我将使用/users/{id}/posts要添加到请求正文中喜欢的帖子列表中的帖子的标识进行 POST 。

与记录用户 1 现在也关注用户 200 和 300 类似，我将/users/{id}/follows在请求正文中发布这些用户的标识。

毕竟，您没有提供用户 1 和其他两个用户之间关系的标识，而是添加了两个新的关系资源，分别将用户 200 和用户 300 作为其“关注用户”属性。

支持您的应用程序的数据库很可能有一个用户表、一个帖子表和一个喜欢表，其中喜欢表是当您记录用户喜欢帖子时添加的表。并且点赞记录的标识不会是用户的标识，也不是帖子的标识，而是有自己的标识（单独或作为用户和帖子标识的组合）。

即使您要将用户喜欢的帖子存储在关系模型之外的其他内容中，甚至可能没有单独的“喜欢”标识，每个“喜欢”的标识仍然是用户和帖子的组合。