这是一个创建于 2343 天前的主题，其中的信息可能已经有所发展或是发生改变。
针对一个功能来说明下：
用户编辑功能：需要编辑用户的基本信息，用户的数据权限信息(如用户可管理的项目)
后端接口设计的时候有两个方案：
- 一个接口载入用户基本信息和项目信息（包含全部项目和用户可管理的项目）；
- 分多个接口实现：用户基本信息接口，项目信息接口；
以上两种方案，一种是后端接口根据页面功能要求来设计接口，另一种方案是后端接口尽量标准，前端来拼装一些业务逻辑，不知哪种更合理。
如用方案 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 ；这才真正发挥前后端分离的优势。
这个其实不仅对技术团队有要求，对设计产品的人也有要求。 |
Select Language