0

我有一个系统，登录的用户可以对帖子投票喜欢或不喜欢。如果他们试图点赞一个已经被点赞的帖子，他们将删除该帖子的投票。同样适用于不喜欢。作为一个 REST 新手，我正在尝试为此提出一个 url 方案，这令人困惑

目前，我的网址看起来像这样

POST /news/vote/social/:feedItemId/:vote(like|dislike|reset)

一个端点正在做所有事情，登录用户才是真正可以投票的用户

在阅读了有关 stackoverflow 的其他一些答案后，似乎还有其他可能性

PUT /news/vote/social/:feedItemId/(like|dislike)
DELETE /news/vote/social/:feedItemId

我已经看到其他答案，其中 userId 也包含在 url 中，因为它说 REST API 设计不应该反映有状态

PUT /news/vote/social/feedItemId/:userId/(like|dislike)
DELETE /news/vote/social/:userId/:feedItemId

这些 url 的问题是任何人都可以更新任何 userId 的投票，除非涉及一些后端检查

我的问题是，考虑到只有登录的人应该只能更新他们的投票，处理这些问题的正确方法是什么？

4

1 回答 1

1

听起来您可能应该看看Custom Methods。

由于这是针对每个用户的操作，因此拥有支持和反对投票的自定义方法非常有意义，其中每个方法都充当 +1 或 -1 的切换。例如：

  • POST /items/1234:upvote在新帖子上会添加 +1（点数=1）
  • POST /items/1234:upvote在同一个帖子上再次会带走赞成票（点数=0）
  • POST /items/1234:downvote在同一个帖子上再次添加-1（点=-1）
  • POST /items/1234:downvote再次在同一个帖子上将取消投票（点数= 0）。

一个额外的考虑是以下顺序：

  • POST /items/5678:upvote会将积分变为 1。
  • POST /items/5678:downvote紧随其后，将取消赞成票并应用反对票，从而将点数从+1变为-1。

（反之亦然）

您提到这需要一些后端检查，这是绝对正确的。如果您在 API 中实现任何用户，只要他们知道用户 ID，任何其他用户都可以对其投赞成票或反对票，那么您就会面临安全风险。因此，处理此问题的正确方法是在用户登录后使用后端从会话中提取用户 ID（而不是从任何人都可以填写他们所代表投票的用户的空白的 URL 中）的）。

于 2022-02-18T13:35:16.227 回答