Question

在以下情形中：

用户可以创建游戏。
创建游戏的用户称为所有者。
游戏在全球范围内拥有自己的唯一ID。
其他用户可以加入他们不拥有的游戏，这些被称为玩家。

有人会向/game/{id}发送请求以获取游戏数据，这对于每个客户都应该是相同的，例如：

{
   name: 'My Game',
   sport: 'Football'
   ...
}

让我们说我们必须展示一个＆＃34;设置＆＃34;主游戏屏幕中游戏所有者的链接。这个＆＃34;设置＆＃34;链接无法显示给常规玩家。

玩家和所有者都可以看到主游戏画面。

如何验证此资源的所有权以向用户显示不同的组件？

我认为在回复中添加ownerId是一种责任，因为可以改变客户端的价值，是吗？
此外，添加isOwner字段会导致无法缓存响应。

Answer 1

这里的答案可能在于HATEOAS类型结构。您的资源应包含其他信息/子/列表等的可导航链接列表。如果＆＃39;设置＆＃39;是请求用户的选项，然后应该返回设置的链接作为对象的一部分，否则不会存在这样的链接。

缓存：这确实存在问题，但它可以解决。

Answer 2

让我们谈谈服务器应用程序和客户端应用程序。客户端应用程序包含主游戏屏幕，并应显示或隐藏某些窗格依赖于某事。

服务器应用程序应提供此某些内容。因为服务器应用程序是REST它应该提供一些追索权。什么样的资源和应该在哪里？

GET /games/{gameId}/users/{userId}/something
GET /users/{userId}/games/{gameId}/something

可以将此某事称为用户的权利或权限。这是独立的资源吗？可能不。所以你可以实现方法

GET /games/{gameId}/users/{userId}

该方法将返回用户的个人资料以及ID为{gameId}的游戏的相应权限，如下所示：

{
    givenNames: 'Miguel de Cervantes',
    familyName: 'Saavedra',
    totalScore: 10342,

    permissions: {
        canClose: false,
        canSetup: false,
        . . .
    }
}

当然，服务器应用程序应检查每个客户端请求的权限。

Answer 3

我认为首先你必须解决与资源责任相关的概念问题，因为返回游戏信息的资源不应该返回“看到或不看按钮”等安全信息。

所以，我会创建一个特定的资源来返回这样的安全信息。在这个特定的安全资源中，对于上面提到的情况，我不会通过URL传递任何参数，并且通过身份验证哈希我将获得用户ID以验证他是否是游戏所有者返回一个简单的响应，如true或false来知道如果该用户可以看到该按钮。

显然，该资源可以回答很多关于其他屏幕和按钮的安全信息。

资源如：

GET /security/buttons/{buttonId}

未来：

GET /security/screens/{screenId}
GET /security/functionalities/{functionalityId}
GET /security/actions/{actionId}
.
.
.

REST API中的资源所有权

3 个答案: