REST API URI 是否应该根据参数授权，而不仅仅是资源？答案

【问题标题】：Should REST API URIs be authorized based on the parameters, not just the resource?REST API URI 是否应该根据参数授权，而不仅仅是资源？
【发布时间】：2021-07-26 02:43:52
【问题描述】：

我正在尝试为我的网络应用程序创建一个后端。该应用程序应该有能够创建关于不同事物的帖子并在需要时编辑它们的用户，以及可以编辑甚至可以编辑的管理员删除不同用户的帖子，如果他们认为这些帖子不好。我在管理用户权限和授权时遇到了问题，尤其是在允许用户访问哪些资源方面，但我已经找到了两种可能的解决方案，但我不确定哪一个是最好的。

使用允许修改自己的数据并将 /users/{id} 资源仅用于使用的特定路径（例如 /users/me） 管理员。
根据给定的 id 是否与身份验证中的用户匹配来处理授权（/users/{id} 只允许您DELETE 或PUT 如果您与基于身份验证令牌的 URI 中的用户是同一用户）。

我想从数据库交互层中抽象出身份验证和授权层，但我发现使用第二种方法很难做到，因为在用户访问资源之前检查用户是否“拥有”资源需要您检索该资源资源，但我也认为第二种方法也有一些优点。

在代码扩展和质量方面，哪一个是最佳架构选择，您会为项目选择哪一个（甚至可能是两者的混合）？

我提到我的后端使用 node.js 和 express 通过 Mongoose 与 MongoDB 数据库交互.

【问题讨论】：

标签： node.js rest express design-patterns architecture

【解决方案1】：

我在你的第二个模型中做了很多事情，在表单的端点中有很多逻辑“可以这个用户对那个操作 em>这样那样的物体”？

如果这些条件成立，我会推荐您的第一个模型。

用户可以对自己的数据做的事情没有特权用户可以对任何用户做的事情复杂。
您可以提出允许某种程度的代码重用的模型（用 MVC 术语）。
API 操作的最大份额将是用户操作自己的数据。

为什么我建议你的第一个选项？

可测试性。可以对最终用户处理自己的数据的一组简单的 API 操作进行测试和回归测试，比依赖更复杂特权的更复杂的 API 集更便宜。
可扩展性。如果您的应用程序向外扩展，您可以将管理 Web 端点移动到它们自己的一个或多个服务器上，而将更简单但访问量很大的用户端点留在另一批服务器上。要使最后一个工作正常，您不需要像/users/me/whatever 和/users/{id}/whatever 这样的端点，而是需要/me/whatever 和/users/{id}/whatever。不要给/me 端点以任何方式让用户（可能是恶意网络爬虫）指定当前用户的会话令牌或凭据以外的用户。
安全。一组功能较弱的端点比一组功能更强大的端点更容易保护。接受较少数据项的端点本质上更安全。（当然，您仍然必须保护管理端点。）

【讨论】：

【解决方案2】：

如果您希望您的 API 是 RESTful 且一致的，您应该选择第二个选项。

在 REST 中，资源由 URL 标识。像 /users/me 这样的 URL 意味着 全局唯一 资源，事实证明并非如此。

替代方案更符合 REST。像/users/1234 这样的URL 表示与/users/5678 不同的 资源。据我所知，这实际上也是你所追求的行为。

从代码可维护性的角度来看，将模型与所需行为保持一致通常是值得的。

这使您能够decouple the identity of the resource from the identity of the client。

【讨论】：