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

Question

我想弄清楚为用户与其他实体交互构建 URL 的正确 RESTful 方式是什么？

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

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

这是我的想法，但我不确定这样做是否正确:

POST/user/:id/like/post/:id(用户喜欢帖子)

POST/user/:id/follow/user/:id(用户关注另一个用户)

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

Answer 1

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

一些一般性评论，摘自RESTful Web Services作者:Leonard Richardson 和 Sam Ruby:

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

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

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

要向用户喜欢的帖子添加帖子，我会 POST 到 /users/{id}/posts 并附上要添加到请求正文中喜欢的帖子列表。

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

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

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

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