基于角色的Web UI与REST

Question

我们为基于Web的新应用程序选择了基于REST的架构。整个平台以RESTful服务的形式公开，因此任何UI（WEB / Mobile）都可以构建在这些服务之上。因此，应用程序分为3层，DB，Application层 - 这只是暴露RESTful服务和UI - 目前是基于HTML5 / CSS / Javascript的UI消费Web服务。

此应用程序还具有基于角色的访问权限，因此必须根据角色设计UI。 Web服务在服务响应中返回特权集然后在Javascript中使用它来构建UI是一个好主意吗？

角色的UI变体可以如下：
主菜单可能会根据角色而改变 标签必须根据角色来控制 应用程序中的大多数页面都是基于小部件的，并且窗口小部件的显示再次标记为角色

再一次，我想知道这是否是一个正确的想法继续下去。请建议。

Answer 1

要遵循HATEOAS（超媒体作为应用程序状态引擎）约束，您应该让REST服务本身提供哪些状态转换（即链接）对“应用程序状态”有效，其中包括根据用户的角色，有关导航，标签等可用的任何特定逻辑。

因此，您的资源设计应该能够返回特定于您登录用户的结果。

E.g。 （使用HAL作为超媒体类型）

GET /users/123/navigation

{
  "_links": {
    "http://api.service.com/rels/home": { "href"="/" "title"="Home" },
    "http://api.service.com/rels/admin": { "href"="/admin" "title"="Admin" }
   }
}

这样做可以保持服务中“哪些角色可以做什么”的业务逻辑，这就是逻辑所属的地方。

Answer 2

为此您需要在数据库中存储所有菜单选项，小部件和页面名称，并在运行时加载菜单。（即您的第一个请求是发送角色和服务器的getMnu）

您可以轻松创建基于角色的Rest Achitecture，并为Restful Services提供安全性。