要面对的问题在于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 以向客户端公开？
- 在第二个解决方案中，根据该特定用户拥有的角色仅返回该特定用户可访问的注意力是否正确？访问终结点并根据其角色仅从该集合(而不是全部(中获取一些资源不是违反直觉吗？
我希望有人能澄清我们正在采取的方法，因为我发现的关于这个问题的文献很少，也没有。
这种过滤有多种解决方案，开发人员必须根据给定的情况选择一种。
根据我的经验，我可以列出以下内容。
结构
当无法直接访问数据并且开发人员必须使用关系(即表 JOIN(时。在这种情况下，URL 必须同时包含主实体和子实体。在使用这种方法之前，一个很好的检查是询问，是否可以将相同的 URL 与 POST 一起使用？
例
如果我们必须获取分配给特定用户的角色列表或想要分配其他角色，那么我们可以使用
GET users/:uid/roles
POST users/:uid/roles
安全
使用多租户系统，每个用户都可以拥有他/她的私有资源，即禁止其他用户访问这些资源。开发人员应保存租户信息并根据当前身份验证筛选资源，而不会打扰客户端或要求 URL 中的任何其他信息
例
用户的电话相册
GET photos
POST photos
搜索
如果它与安全性或结构无关，但客户端仍希望根据其方案筛选结果集。 然后，开发人员应使用查询字符串进行筛选。
例
客户必须从他/她的收件箱或发件箱中获取邮件，或者想要尚未阅读的邮件。 或者他/她想搜索他/她的收件箱
GET messages?folder=inbox
GET messages?folder=inbox&status=unread
GET messages?search=nasir