我们有一个 Multi-Tenancy 系统，具有多个不同级别的访问权限——有时甚至是同一用户在多个角色之间切换时也是如此。我们开始讨论转向 RESTful 实现。我刚刚开始对整个 REST 事情感到困惑。
那么，当他们访问资源时，我该如何限制对正确记录的访问，尤其是在考虑缓存时？如果用户A访问example.com/employees他们将收到与用户 B 不同的响应；当用户 A 切换到不同的角色时，他甚至可能会收到不同的响应。为了帮助促进缓存，角色的 id 是否应该以某种方式合并到 uri 中？也许像 example.com/employees/123 (这违反了 REST 的规则)，或者作为某种从属资源，如 example.com/employees/role/123 (这似乎很愚蠢，因为 role/### 将被附加到所有地方的 URI 中)。我可以帮忙，但我认为我在这里遗漏了一些东西。
编辑提及 Multi-Tenancy
最佳答案
让用户凭据充当带外资源标识符(即，将同一 URL 上的不同 View 呈现给不同角色)将变得令人讨厌。用户和应用程序在它们之间交换 URL，当这种情况发生时，事情会变得很糟糕，并且 URL 只是为不同的凭据返回不同的内容。
我想说每个角色都有不同的世界观，因此每个角色应该访问不同的服务路径:
通过这种方式，您可以将“此角色看待世界如此这般”部分与“角色 foo 可以访问此世界观”部分分开。管理员可以连接到 example.com/users/employees 并验证普通用户如何看待这个世界，而管理员不必首先冒充较低特权的别名。
您也可以将 DNS 部分用于相同目的:admin.example.com/employees 与 users.example.com/employees。这对于相关场景特别可行，当“角色”不是安全角色而是 Multi-Tenancy 命名空间时(即，每个服务供应帐户都有自己的服务“ View ”)。
关于使用多个用户角色进行 REST、缓存和授权，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2671582/