针对管理员和非管理员帐户的Restful api设计

面临如何为管理员和非管理员帐户设计api的问题。我遵循MVC模式，其中控制器将映射到uri

组合场景：
比如说，我有一个系统，允许用户在花钱购买商品并收集积分后兑换礼物

我的系统有一个用户配置文件、礼品和兑换表。 每个用户可以兑换许多礼物，每个礼物可以由许多用户兑换。（兑换是连接表）

要访问用户配置文件，uri如下：

GET /user/0001

赎回礼物

POST /user/0001/redeem {"amount":1, "address":"old address"}

到目前为止，一切看起来都很整洁。现在，当兑换需要管理员用户批准时，问题就出现了

因此，要将兑换更新为已批准状态

PUT /user/0001/redeem/100 {"status":"approve"}

用户可以更新礼品将运送到的配送地址

PUT /user/0001/redeem/100 {"address":"New address"}

现在我面临以下问题：

如果2个路径指向uri，控制器将在同一个函数中有2个不同的处理代码。1个If块用于admin，1个If块用于user

如果我在uri前面添加一个admin（admin/user/0001/redemble/100）。2个不同的路径将标识相同的资源

在授权标头（Authorization=“USERNAME:SECURITY\u HASH”）上完成了标识用户身份的操作。这是一种典型的restful方法吗

我无法区分用户角色，因为管理员和用户存储在不同的表中。因此，如果uri指示用户角色，这将使事情变得更简单。我不想总是在用户之前查询admin表

---

我会这样做：

1） 有像POST/admin/user/1000/兑换/批准这样的URL

原因:

• 我不想公开有关必须更改用户记录中的哪个字段才能批准凭证的知识

• 我更喜欢将所有管理操作与正常用户操作分开

2） “常用”方法之一是在成功登录后发布（定期更新）会话cookie（与用户名或密码散列无关），然后单独使用一种机制将此cookie与用户名关联，并检查是否允许此用户名执行给定操作

原因：减少了暴露用户信息的危险。（如果攻击者窃取cookie，此方法可能仍然容易受到攻击，但另一种方法也是如此）

---

3） 如果我们谈论安全性，那么将管理员和用户数据存储在不同的表中并不是借口：）使用上面描述的cookie机制在这里可能会有所帮助，但您仍然需要确定验证给定用户是否可以调用给定方法的方法。

感谢您的快速回复。Restful强调无状态意味着会话cookie将违反该约束。Restful也不建议使用动词进行操作。approve可以替换为幂等put方法。