基于RBAC模型的RESTful API设计

Question

要面对的问题在于RESTful API的设计，该API可以管理基于RBAC的解决方案中多个角色的请求。

当前，我们有可以从不同用户访问的不同资源，可以根据他们的特权将一个或多个角色分组。

我们正在尝试定义的API必须对客户端尽可能清晰，但不增加向URL添加其他元数据的开销，这些元数据可能会破坏甚至与REST的实践和定义冲突。因此，我们必须不惜一切代价避免在URL中包含有关角色的信息。该计划是使用JWT令牌，这些令牌在其有效负载中携带所需信息，以了解用户发出请求的权限。

提出了我们的当前情况，让我们提供一个示例并说明要解决的问题：

[假设我们有*金融家*和*提供者*作为具有某些角色的用户，都希望获得**关注**（我们的资源）。我们是否应该在资源**注意**之前添加有关*用户*尝试访问资源的信息？

在这种情况下，端点应定义为：]

https://example.com/api/v1/financiers/:id/attentions
https://example.com/api/v1/providers/:id/attentions
通过这种方式，我们试图通知各个控制器，我们希望对特定角色/用户的关注**，在某种程度上，它们是它们的子资源。

另一方面，我们可以简单地实现一个更简单的端点，如下所示：

https://example.com/api/v1/attentions
现在应该从一种独特的方法中实现关于从数据库返回注意力的逻辑，该方法必须处理这两个角色（以下功能可能包含新角色）。必须从令牌的有效负载中获取所有所需的信息，从而公开更为通用的API，并释放Web客户端的责任，取决于角色取决于哪个端点调用。

我想强调一点，注意是在微服务体系结构中管理的，因此，将它们检索的逻辑收集在单个服务中。从第一个解决方案路由两个（或可能更多）端点的API网关的成本是一个可变因素，在我们的特定情况下不容丢弃。

暴露了我们的当前状况：

• 我们将是处理此问题的最佳方法？
• 是否有没有其他替代方案可以简化角色管理并提供干净的API公开给客户端？
• 在第二种解决方案中，根据它所具有的角色只返回该特定用户可以访问的注意力是正确的吗？访问端点并根据其角色仅从该集合中获取部分资源（并非全部）是否违反直觉？

[我希望有人能澄清我们所采用的方法，因为关于此问题的文献很少，也没有文献。

面临的问题在于RESTful API的设计，该API可以管理基于RBAC的解决方案中来自多个角色的请求。当前，我们有不同的资源，可以从...

Answer 1

这种过滤有多种解决方案，开发人员可以根据特定情况选择一种。