策略和资源客户端/rest api 端

Question

我正在我的旧 MVP 遗留项目中开发一个新的 REST API，我想改善我自己的客户（网络、android 和 ios）的体验。

假设，用户可以上传/修改/删除他们自己的图片。此外，如果用户具有管理员级别，将能够对任何图片应用任何操作。

如您所见，逻辑可能会增长并具有越来越重的业务逻辑。实际上，我有一些政策，我们会检查很多有关用户、角色、资源等的内容，并且根据用户的不同，每个权限都会发生变化。

关于 API，我在可扩展性方面有很多疑问和选择：

1. API 是否应该使用布尔值告诉客户端每个可能的操作？ 示例：

Request to --> /api/capabilities/pictures/{pictureId}
(We'll figure out who is the requester by the token attached in the request header.)

{
 "canUpload": true,
 "canUpdate": false,
 "canRemove": true
}

2. 逻辑是否应该在每个客户端（当然也应该在后端）？
3. 逻辑是否应该在资源本身中作为响应的一部分？

GET /api/pictures/{pictureId}
{
   "id":"pictureId",
   "URL": "pictureUrl,
   "capabilities":{
      "canUpload":true,
      "canUpdate":false,
      "canRemove":true
   }
}

我的常识是这应该是后端中的一切。如果我们将所有这些检查都移到 Backend 中，Frontend 最终会有什么样的逻辑？只是阅读布尔值？

就我的新 REST API 的可扩展性而言，哪个选项是最好的？如果您知道其他第四种选择，请告诉我。

我们为什么要这个？前端需要知道它，因为它会根据政策打印按钮/新布局/任何内容。

PD：为了更简单，让我们假设每个客户都有相同的逻辑。