api - 对实现 HATEOAS 的 rest API 的权限

Question

我试图找出在单页应用程序中处理权限的正确方法，该应用程序直接与实现 HATEOAS 的几个 RESTful API 对话。

举个例子:

“作为我的应用程序的用户，我可以查看、启动和暂停作业，但不能停止它们。”

底层的 rest API 具有以下资源:

/工作/{id}
它接受 GET 和 PUT。 GET 返回一个作业模型，PUT 接受一个作业模型作为请求体，格式如下:

{
 "_links" : {
     "self" : "/jobs/12345678"
 }
 "id" : 12345678,
 "description" : "foo job",
 "state" : "STOPPED"
}

接受的工作状态可以是:休眠 |运行 |暂停 |停了下来。

要求说在 UI 上我必须有按钮:

开始、暂停、停止

...并且仅根据登录用户的权限显示。

从 API 的角度来看，一切正常，因为服务器上的底层逻辑确保用户在发出请求时无法将状态更新为 STOPPED 状态(可能返回 401)。

将用户权限告知应用程序/UI 的最佳方法是什么，以便它可以隐藏用户无权操作的任何按钮？

API 是否应提供权限列表，可能类似于:

{
 "_links" : {
     "self" : "/permissions",
     "jobs" : "/jobs"
 }
 "permissions" : { 
     "job" : ["UPDATE", "DELETE"], 
     "job-updates" : ["START", "PAUSE"] 
  }
}

或者 API 是否应该更改以便权限反射(reflect)在 HATEOS 链接中，可能类似于:

{
 "_links" : {
     "self" : "/jobs/12345678",
     "start" : "/jobs/12345678/state?to=RUNNING", 
     "pause" : "/jobs/12345678/state?to=PAUSED", 
 }
 "id" : 12345678,
 "description" : "foo job",
 "state" : "DORMANT"
}

还是应该以完全不同的方式完成？

更新

我发现以下文章给出了答案:
https://softwareengineering.stackexchange.com/questions/215975/how-to-handle-fine-grained-field-based-acl-permissions-in-a-restful-service

Answer 1

我会选择后者:根据存在的链接暗示权限。

如果链接不存在，则用户无法访问资源/执行操作。如果是，他们可以。这就是我要做的，因为它简单而干净，前端代码几乎不用考虑。解耦，哟。

或者，如果您确实想在每个响应中包含所有链接，但明确指定哪些是允许的，哪些是不允许的，如果您使用诸如 HAL 之类的格式来编写您的链接，您可以在每个链接上使用一个标志来扩展它，例如所以:

{
    "_links" : {
        "self" : {
            "href":"/jobs/12345678",
            "allowed":false
        },
        "start" : {
            "href":"/jobs/12345678/state?to=RUNNING",
            "allowed":false
        },
        "pause" : {
            "href":"/jobs/12345678/state?to=PAUSED",
            "allowed":false
        }
    },
    "id" : 12345678,
    "description" : "foo job",
    "state" : "DORMANT"
}