前后端分离接口设计以及权限的疑惑

[jsrgqinbin]

针对一个功能来说明下：

用户编辑功能：需要编辑用户的基本信息，用户的数据权限信息(如用户可管理的项目)

后端接口设计的时候有两个方案：

1. 一个接口载入用户基本信息和项目信息（包含全部项目和用户可管理的项目）；
2. 分多个接口实现：用户基本信息接口，项目信息接口；

以上两种方案，一种是后端接口根据页面功能要求来设计接口，另一种方案是后端接口尽量标准，前端来拼装一些业务逻辑，不知哪种更合理。

如用方案 2 就存在另一个权限问题：

如用户编辑作为一个权限验证，用方案 2 的接口设计的话，用户编辑的功能权限就会涉及到用户和项目的两个权限的交叉。如只分配给用户用户编辑权限，不分配项目的权限，那即使能编辑用户，进页面也载入不了项目的信息。

相信这样的问题应该有好多人会遇到，求比较好的方案。

[hlwjia]

产品设计不合理

理想化应该是方案二，但是对整个团队（包括产品）要求高；

方案一比较适合团队成员水平普遍一般的情况，后期可能接口会越来越多，难维护

[hlwjia]

/users/id/projects 返回这个用户的项目就可以了

[hlwjia]

你的描述其实很模糊，用户出现了很多次，感觉有些用户是用户，有些是 admin

[jsrgqinbin]

@hlwjia 因为是 TOB 的系统，都是用户，管理员只能算是一个用户的角色，分配的权限就可以使用这个功能，不分配就不能使用。

[hlwjia]

建议你把你的 case 再说清楚一点。

你现在是作为一个 user 可以给编辑其他 user ? 然后能分配项目权限给其他 user?

你现在这个 user 是怎么得来这个权限的？还是你其实是后台的 admin, 你去操作在平台注册的那些 user ？

[reus]

基本信息和项目信息当然分开两个接口，如果后期再出现其他可以管理的东西，那一个接口会越来越大
权限当然也要分开，可以引入权限组，也就是一个组对应几个权限，前端可以传入一个组名，或者独立的权限
不要根据前端页面的需求设计接口，因为前端页面可能会变的，总不能前端需求变了你后端也跟着变吧？把接口设计得通用，那前端需求调整时，后端的调整有时就可以省下了。

[huisezhiwei]

就楼主提出的 2 个方案比较， 明显方案 2 更加符 restful 接口的设计规范。
对于“用户”和“项目”两个概念， 可以根据具体的系统功能来从两者之间找寻一个 ”聚合根“，作为数据引用的入口。
至于权限上， 个人觉得可以将 读、 写两种权限分别看待。 对于只读接口，权限可以相对放宽一些。 而写操作，一般也只会允许项目所属的用户进行编辑。而不是单纯从”用户“ 、 ”项目“ 两个概念上单独的去考虑权限。

[annielong]

权限问题还要看具体用户场景，我们这边都是做权限组角色，然后给用户分配角色，但是用户这边总有各种各样的权限要求，不得不一种角色做了好几个权限组，如销售员 A，销售员 B，里面的权限甚至只会有一个不同而已，

[TommyLemon]

APIJSON 就是一个很好的解决方案啊，
自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。
支持对表对象单独设置权限。

通过自动化 API，前端可以定制任何数据、任何结构！
大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！
前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！
后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！

在线解析
自动生成文档，清晰可读永远最新
自动生成请求代码，支持 Android 和 iOS
自动生成 JavaBean 文件，一键下载
自动管理与测试接口用例，一键共享
自动校验与格式化 JSON，支持高亮和收展

对于前端
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度

对于后端
提供通用接口，大部分 API 不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本、自动防 SQL 注入
开放 API 无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等

后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
https://github.com/TommyLemon/APIJSON
创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^

[TommyLemon]

URL: /get
Reuqest:
```javascript
{
"Moment": {
"@role": "owner"
},
"User": {
"@role": "circle",
"id@": "Moment/userId",
"@column": "id,name"
}
}
```
Response:
```javascript
{
"Moment": {
"id": 1528333667271,
"userId": 82001,
"date": "2018-06-07 09:07:47.0",
"content": "说点什么吧~s",
"praiseUserIdList": [
82001
]
},
"User": {
"id": 82001,
"name": "测试改名"
},
"code": 200,
"msg": "success"
}
```

后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
github.com/TommyLemon/APIJSON
创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^

[nickfan]

讲具体一点的问题的场景：

比如页面上要求返回
[版块对象] ， [帖子列表] ， [本页用户列表] 3 组后端 api 接口的调用，但整个页面叫：

[版块帖子列表查看 url]

传统的 mvc 开发方式是 controller 层先
1.对当前用户 [版块帖子列表查看 url] 的权限鉴权后：
2.分别调 3 个 service/repository 层接口然后聚合返回渲染界面。

如果前后端分离的时候面对的问题是：

一、如果前端 rest 接口层分别提供 [版块对象] ， [帖子列表] ， [本页用户列表] 的直接 api 接口调用，
那么？
1.1 一个 [版块帖子列表查看 url] 的权限项要拆分为当前用户对 [版块对象] ， [帖子列表] ， [本页用户列表] 3 个接口的分别权限鉴权。如果后台管理上来说，本来运营人员只需要分配用户 A 对 [版块帖子列表查看 url] 的权限项，而现在运营人员要分配用户 A 对 [版块对象] ， [帖子列表] ， [本页用户列表] 3 项的权限项才能让用户完整的看到 [版块帖子列表查看 url] 页面。
1.2 拆 3 个接口的分别 api 接口调用增加了 http 连接数和传输量，鉴权的中间数据也要做 3 次，就算有缓存也有存取的开销。

二、而如果把本页的所有接口统一为 [版块帖子列表查看 url] 权限项，接口的耦合性搞了，页面重构，这部分代码也得重新改，而不像拆成各个独立接口对于后端不用重复开发。


选哪种方式有点不知道如何取舍。

[nickfan]

如上所述的场景，各位觉得应该如何取舍

@hlwjia @reus @huisezhiwei

[hlwjia]

@nickfan 还是我在这个帖子里的第一个回答，看团队整体情况，如果团队整体素质可以，并且愿意去这样做，方案一长远来看肯定是更好的；对于鉴权次数和 http 连接数这些我个人观点是太早了考虑了，而且如果项目真的大到一定规模，你的每个模块请求发到后端都对应的是各自的服务了，比如账户模块发到的是账户服务，支付专门有支付服务，等等。

如果是干一票的话，第二种也可以，但是也没有前后端分离的必要了

[hlwjia]

@nickfan API 服务应该是要能对客户端无感的，比如小程序，iOS，Android，Windows Phone，Mobile Web 和 Desktop Web 都应该是通用一套 API ；这才真正发挥前后端分离的优势。

这个其实不仅对技术团队有要求，对设计产品的人也有要求。

[nickfan]

@hlwjia 那方案一的问题，暂时不考虑鉴权次数性能，http 连接数等问题的前提下，

[版块帖子列表查看 url] 的这一个权限项在后台的管理里就要分散成 3 个 api 接口的请求权限项+一个菜单访问的权限项，而且对于运营人员而言还要了解这一个界面上有哪些权限项需要赋值。

[hlwjia]

理论上这个东西要做成 role based 的好，就是这个系统分为几种角色，每个身份有对应的权限。这些应该是这个系统应该有的默认 preset，然后运营人员可以去针对每个角色增或者减权限。
@nickfan