首先，我想稍微提一下架构。
我们有一个UI应用程序，它使用REST api进行所有操作和用例。 UI应用程序使用凭据来调用REST api，因为还有其他非UI应用程序使用相同的服务。
我们使用Spring Security对REST api应用程序进行身份验证和授权。实际上整个应用程序从上到下使用Spring组合。
对于UI应用程序上的操作的身份验证和授权，我们也使用Spring Security。我们保护网址并仅向当前登录的用户显示他有权执行的操作。
以下是新要求：某些登录用户会看到有限制的资源。这意味着相同的资源显示更少的字段或更少的可更新字段。
探索周围，我们缩小到两种方法：
如果资源表示组合太多，则不同的资源对象可能不太可维护。可以实现基于HTTP头的自动限制器方面。客户端也提供了一些标题，这为客户端增加了一点复杂性。
如果组合不是太多，则为每个受限访问创建新资源。客户必须在合适的时间拨打正确的电话。这种方法可以揭示隐藏的领域概念，因为新的资源和设计可能看起来更干净。
你有什么想法？你会采取哪种方法？
答案 0 :(得分：0)
从你的架构中，我猜你已经安装了安全过滤器（我相信它在Spring中被称为OncePerRequestFilter？）。我过去采用这种方式的方法是使用我的安全过滤器来获取客户端的“角色”（假设您可以为每个客户端分配角色，映射到每个资源对象的特定权限/限制）。现在基于“角色”我有自定义JSON序列化器/解串器策略（我使用GSON用于此包含/排除类型适配器。您可以阅读更多here (Gson custom seralizer for one variable (of many) in an object using TypeAdapter)）来处理应该/不应该是哪些资源字段填充/序列化。这样，您将继续为每个资源对象使用相同的资源对象和TypeAdapter，这将根据客户端的角色确定资源对象的序列化/反序列化。
我想到的另一个想法是方法拦截器（Spring AOP）。虽然我从来没有尝试过使用方法拦截器，但我认为它应该仍然可以在你返回之前（以及在完成业务逻辑之后）截取方法，并查看发出请求的客户端的角色。基于该角色，您可以确定哪些字段为空（大多数序列化程序（atleast gson）不序列化空字段）而不是序列化，然后将其转换为json（或任何返回类型）并将其发送到客户端
我希望这会有所帮助。