
跟朋友忽然聊到一个话题,这种前后端分离的项目,例如 APP 开发,接口由客户端定义比较好,还是服务端? 当然各有利弊,我们公司一直都是服务端定义的,然后客户端审核,对细节进行商量修改。
服务端定义,好处大概是: 1.服务端知道存储和逻辑的处理,他们知道怎么更方便、快捷的把数据给出。 2.很多验证类的,安全类的事情,基本上也是服务端控制。 3.客户端考虑的很多是页面跳转,服务端考虑流程处理,相对而言,服务端在考虑流程的时候,接口定义也就一同考虑进去了
客户端定义,优点: 客户端相当于消费者,他们知道自己需要什么,不需要什么。 客户端接口定义比较好,客户端开发,加载更高效。实际上在开发的时候,也的确容易出现服务端、客户端相互扯皮的情况,客户端要某种形式的接口,服务端说这样影响运行效率或者开发困难等
不知道大家公司的流程是什么样的,欢迎讨论
1 gdtv 2017 年 7 月 23 日 借地问一下:如果 app 一个页面上有几部分内容,例如要显示用户信息、分类一的文章、分类二的文章、分类三的文章,应该在一个接口里同时返回这些内容,还是分成多个接口? 目前我们团队开发的 app,是在一个接口里同时返回这些内容,但这样的话接口开发就比较麻烦,每个页面都要有一个专用的接口,一个 app 往往有几十个页面,结果要开发几十个接口。 如果分成多个接口,例如上面的需求,只要开发一个用户信息接口和一个文章接口,然后前端根据分类 id 就可以调用不同分类的文章。但这样的话 app 一个页面就要多次调用接口。 |
2 yidinghe 2017 年 7 月 23 日 via Android 大家一起商量,谁也不要偷懒,尽量站在自己角度去提要求,你自己不为自己着想,还指望别人啊?没一点积极性,对得起给你发薪水的老板吗? |
3 piaochen OP @gdtv 我做的项目,基本上都是分成多个接口来处理的。 分成多个接口来处理, 优点: 1.更好的能适应需求变更。例如首页要显示信息 a,b,c,结果下个需求,c 不要在首页中显示,移到其他页面了。这样的话,接口都不需要动。假如接口按照页面给的话,要改两个接口。服务端,客户度都要动,还要重新联调。 2.接口按页面给出,对一些数据量比较大的页面,很可能出现一个接口,数据很大的情况。可能性能上,会比较麻烦。 3.很多分页加载的列表,也只能按接口给出列表需要的数据,不可能一次性把页面上的数据都全部一次性给出。 4.有利于客户端做部分数据缓存的工作。 缺点: 1.就是为了加载一个页面,可能要加载很多接口,导致页面加载速度有点慢。这个我们都是靠优化来解决,有些数据的获取,可以放在登录、APP 初始化的时候,数据量比较小的页面,分担一些通用数据获取的工作。有些不常更改的数据,可以直接通过版本控制的方式,缓存在客户端。 2.部分数据接口之间,有依赖关系。这个也要处理好。 |
4 gdtv 2017 年 7 月 23 日 @piaochen 我们团队为了“更好的能适应需求变更”,决定用单一接口来处理,“例如首页要显示信息 a,b,c,结果下个需求,c 不要在首页中显示” 此时只要修改接口不返回 C 的内容就行,不用修改 APP,不用重新打包,不用重新上架. 我是做后端接口开发的,我当然想分成多个接口,这样我少很多工作。 |
5 akrf 2017 年 7 月 23 日 via Android 谁牛逼谁定义 |
6 piaochen OP @gdtv 这个应该属于两种风格吧,我们这边跟你们那恰恰相反,服务端希望每个页面一个接口,我是客户端,我希望每个都单独起来比较好。 你说的这种情况,我觉得应付简单的需求变更比较好,假如需求变更频繁,也比较麻烦。我们这边,APP 每个页面,都基本上要重新做个 3,4 遍.... |
7 Ouyangan 2017 年 7 月 23 日 后端 |
8 also24 2017 年 7 月 23 日 客户端提接口需求(包括风格建议) 服务端出接口细节 至于接口按页面给出还是按单个功能给出,这个应该是开发 leader 定吧 |
9 EagleB 2017 年 7 月 23 日 共同决定 |
11 junwuhui 2017 年 7 月 23 日 via Android 前端提需求,后端初步设计,前后再商量 |
12 pagict 2017 年 7 月 23 日 via iPhone 我以为,接口的设计原则应该让接口客户使用起来简单易懂。所谓接口,不就是这套调用的开发者对用户做的封装和承诺么,当然要隐藏细节,简洁啦 |
13 mingyun 2017 年 7 月 24 日 先双方定好怎么实现,然后后端初步写好接口文档,再和前端修改确认 |