APP 的接口应该由谁定义比较好？前端，后端？

[piaochen]

跟朋友忽然聊到一个话题，这种前后端分离的项目，例如 APP 开发，接口由客户端定义比较好，还是服务端？ 当然各有利弊，我们公司一直都是服务端定义的，然后客户端审核，对细节进行商量修改。

服务端定义，好处大概是： 1.服务端知道存储和逻辑的处理，他们知道怎么更方便、快捷的把数据给出。 2.很多验证类的，安全类的事情，基本上也是服务端控制。 3.客户端考虑的很多是页面跳转，服务端考虑流程处理，相对而言，服务端在考虑流程的时候，接口定义也就一同考虑进去了

客户端定义，优点： 客户端相当于消费者，他们知道自己需要什么，不需要什么。 客户端接口定义比较好，客户端开发，加载更高效。实际上在开发的时候，也的确容易出现服务端、客户端相互扯皮的情况，客户端要某种形式的接口，服务端说这样影响运行效率或者开发困难等

不知道大家公司的流程是什么样的，欢迎讨论

[gdtv]

借地问一下：如果 app 一个页面上有几部分内容，例如要显示用户信息、分类一的文章、分类二的文章、分类三的文章，应该在一个接口里同时返回这些内容，还是分成多个接口？

目前我们团队开发的 app，是在一个接口里同时返回这些内容，但这样的话接口开发就比较麻烦，每个页面都要有一个专用的接口，一个 app 往往有几十个页面，结果要开发几十个接口。

如果分成多个接口，例如上面的需求，只要开发一个用户信息接口和一个文章接口，然后前端根据分类 id 就可以调用不同分类的文章。但这样的话 app 一个页面就要多次调用接口。

[yidinghe]

大家一起商量，谁也不要偷懒，尽量站在自己角度去提要求，你自己不为自己着想，还指望别人啊？没一点积极性，对得起给你发薪水的老板吗？

[piaochen]

@gdtv 我做的项目，基本上都是分成多个接口来处理的。
分成多个接口来处理，
优点：
1.更好的能适应需求变更。例如首页要显示信息 a,b,c，结果下个需求，c 不要在首页中显示，移到其他页面了。这样的话，接口都不需要动。假如接口按照页面给的话，要改两个接口。服务端，客户度都要动，还要重新联调。
2.接口按页面给出，对一些数据量比较大的页面，很可能出现一个接口，数据很大的情况。可能性能上，会比较麻烦。
3.很多分页加载的列表，也只能按接口给出列表需要的数据，不可能一次性把页面上的数据都全部一次性给出。
4.有利于客户端做部分数据缓存的工作。
缺点：
1.就是为了加载一个页面，可能要加载很多接口，导致页面加载速度有点慢。这个我们都是靠优化来解决，有些数据的获取，可以放在登录、APP 初始化的时候，数据量比较小的页面，分担一些通用数据获取的工作。有些不常更改的数据，可以直接通过版本控制的方式，缓存在客户端。
2.部分数据接口之间，有依赖关系。这个也要处理好。

[gdtv]

@piaochen 我们团队为了“更好的能适应需求变更”，决定用单一接口来处理，“例如首页要显示信息 a,b,c，结果下个需求，c 不要在首页中显示” 此时只要修改接口不返回 C 的内容就行，不用修改 APP，不用重新打包，不用重新上架.

我是做后端接口开发的，我当然想分成多个接口，这样我少很多工作。

[akrf]

谁牛逼谁定义

[piaochen]

@gdtv 这个应该属于两种风格吧，我们这边跟你们那恰恰相反，服务端希望每个页面一个接口，我是客户端，我希望每个都单独起来比较好。
你说的这种情况，我觉得应付简单的需求变更比较好，假如需求变更频繁，也比较麻烦。我们这边，APP 每个页面，都基本上要重新做个 3,4 遍....

[Ouyangan]

后端

[also24]

客户端提接口需求（包括风格建议）
服务端出接口细节

至于接口按页面给出还是按单个功能给出，这个应该是开发 leader 定吧

[EagleB]

共同决定

[devilyaos]

@gdtv 回答 1 楼，叫 app 进页面用缓存的用户数据，然后异步获取文章列表

[junwuhui]

前端提需求，后端初步设计，前后再商量

[pagict]

我以为，接口的设计原则应该让接口客户使用起来简单易懂。所谓接口，不就是这套调用的开发者对用户做的封装和承诺么，当然要隐藏细节，简洁啦

[mingyun]

先双方定好怎么实现，然后后端初步写好接口文档，再和前端修改确认