针对一个功能来说明下:
用户编辑功能:需要编辑用户的基本信息,用户的数据权限信息(如用户可管理的项目)
后端接口设计的时候有两个方案:
以上两种方案,一种是后端接口根据页面功能要求来设计接口,另一种方案是后端接口尽量标准,前端来拼装一些业务逻辑,不知哪种更合理。
如用方案 2 就存在另一个权限问题:
如用户编辑作为一个权限验证,用方案 2 的接口设计的话,用户编辑的功能权限就会涉及到用户和项目的两个权限的交叉。如只分配给用户用户编辑权限,不分配项目的权限,那即使能编辑用户,进页面也载入不了项目的信息。
相信这样的问题应该有好多人会遇到,求比较好的方案。
1
hlwjia 2018-07-22 22:52:00 +08:00 via iPhone 1
产品设计不合理
理想化应该是方案二,但是对整个团队(包括产品)要求高; 方案一比较适合团队成员水平普遍一般的情况,后期可能接口会越来越多,难维护 |
2
hlwjia 2018-07-22 22:54:11 +08:00 via iPhone
/users/id/projects 返回这个用户的项目就可以了
|
3
hlwjia 2018-07-22 22:55:40 +08:00 via iPhone
你的描述其实很模糊,用户出现了很多次,感觉有些用户是用户,有些是 admin
|
4
jsrgqinbin OP @hlwjia 因为是 TOB 的系统,都是用户,管理员只能算是一个用户的角色,分配的权限就可以使用这个功能,不分配就不能使用。
|
5
hlwjia 2018-07-22 23:34:12 +08:00
建议你把你的 case 再说清楚一点。
你现在是作为一个 user 可以给编辑其他 user ? 然后能分配项目权限给其他 user? 你现在这个 user 是怎么得来这个权限的?还是你其实是后台的 admin, 你去操作在平台注册的那些 user ? |
6
reus 2018-07-23 08:37:33 +08:00
基本信息和项目信息当然分开两个接口,如果后期再出现其他可以管理的东西,那一个接口会越来越大
权限当然也要分开,可以引入权限组,也就是一个组对应几个权限,前端可以传入一个组名,或者独立的权限 不要根据前端页面的需求设计接口,因为前端页面可能会变的,总不能前端需求变了你后端也跟着变吧?把接口设计得通用,那前端需求调整时,后端的调整有时就可以省下了。 |
7
huisezhiwei 2018-07-23 08:37:54 +08:00
就楼主提出的 2 个方案比较, 明显方案 2 更加符 restful 接口的设计规范。
对于“用户”和“项目”两个概念, 可以根据具体的系统功能来从两者之间找寻一个 ”聚合根“,作为数据引用的入口。 至于权限上, 个人觉得可以将 读、 写两种权限分别看待。 对于只读接口,权限可以相对放宽一些。 而写操作,一般也只会允许项目所属的用户进行编辑。而不是单纯从”用户“ 、 ”项目“ 两个概念上单独的去考虑权限。 |
8
annielong 2018-07-23 09:24:49 +08:00
权限问题还要看具体用户场景,我们这边都是做权限组角色,然后给用户分配角色,但是用户这边总有各种各样的权限要求,不得不一种角色做了好几个权限组,如销售员 A,销售员 B,里面的权限甚至只会有一个不同而已,
|
9
TommyLemon 2018-07-23 10:04:42 +08:00
APIJSON 就是一个很好的解决方案啊,
自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果, 期间自动校验权限、结构、内容,自动防 SQL 注入。 支持对表对象单独设置权限。 通过自动化 API,前端可以定制任何数据、任何结构! 大部分 HTTP 请求后端再也不用写接口了,更不用写文档了! 前端再也不用和后端沟通接口或文档问题了!再也不会被文档各种错误坑了! 后端再也不用为了兼容旧接口写新版接口和文档了!再也不会被前端随时随地没完没了地烦了! 在线解析 自动生成文档,清晰可读永远最新 自动生成请求代码,支持 Android 和 iOS 自动生成 JavaBean 文件,一键下载 自动管理与测试接口用例,一键共享 自动校验与格式化 JSON,支持高亮和收展 对于前端 不用再向后端催接口、求文档 数据和结构完全定制,要啥有啥 看请求知结果,所求即所得 可一次获取任何数据、任何结构 能去除重复数据,节省流量提高速度 对于后端 提供通用接口,大部分 API 不用再写 自动生成文档,不用再编写和维护 自动校验权限、自动管理版本、自动防 SQL 注入 开放 API 无需划分版本,始终保持兼容 支持增删改查、模糊搜索、正则匹配、远程函数等 后端接口和文档自动化,前端(客户端) 定制返回 JSON 的数据和结构! https://github.com/TommyLemon/APIJSON 创作不易,GitHub 右上角点 Star 支持下吧,谢谢^_^ |
10
TommyLemon 2018-07-23 10:10:11 +08:00
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 支持下吧,谢谢^_^ |
11
nickfan 2018-07-23 10:22:50 +08:00
讲具体一点的问题的场景:
比如页面上要求返回 [版块对象] , [帖子列表] , [本页用户列表] 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] 权限项,接口的耦合性搞了,页面重构,这部分代码也得重新改,而不像拆成各个独立接口对于后端不用重复开发。 选哪种方式有点不知道如何取舍。 |
12
nickfan 2018-07-23 13:45:50 +08:00
|
13
hlwjia 2018-07-23 14:23:45 +08:00
@nickfan 还是我在这个帖子里的第一个回答,看团队整体情况,如果团队整体素质可以,并且愿意去这样做,方案一长远来看肯定是更好的;对于鉴权次数和 http 连接数这些我个人观点是太早了考虑了,而且如果项目真的大到一定规模,你的每个模块请求发到后端都对应的是各自的服务了,比如账户模块发到的是账户服务,支付专门有支付服务,等等。
如果是干一票的话,第二种也可以,但是也没有前后端分离的必要了 |
14
hlwjia 2018-07-23 14:31:01 +08:00
@nickfan API 服务应该是要能对客户端无感的,比如小程序,iOS,Android,Windows Phone,Mobile Web 和 Desktop Web 都应该是通用一套 API ;这才真正发挥前后端分离的优势。
这个其实不仅对技术团队有要求,对设计产品的人也有要求。 |