关于 API 的设计，是一个 API 包含三个结构体还是每个 API 一个结构体呢？

[beneo]

我们的架构是前后端分离的，我是写 Java 的，要向 App、H5、PC 等提供接口；之前我们的业务比较简单，基本上一个页面一个 API，慢慢业务起来了，API 的返回结构体开始复杂，我们后端也开始做复用和抽象；

今天和 App 开发争论一个问题。App 上有个页面，里面分成三大块，每块都是一个 Excel 的结构体，而且每个 Excel 的结构体，在其他好几个页面上面，都有复用。某一个页面需要一个，另外一个页面需要另一个，这样的情况；

目前 App 那边一直坚持这个页面只要一个 API，一次返回三个结构体；原因是对用户体验友好。

而我做后端的觉得，这个 Excel 结构体复用的地方比较多，想做到单一职责，应该分三个 API 来调用；

我想问问大家怎么看这个问题，有没有比较正确的姿势来解

[ytmsdy]

key word: API Gateway

[beneo]

@ytmsdy 不明白兄台这个关键词说明了什么问题，请明示
@ytmsdy

[beneo]

@ytmsdy 我们使用 zuul 来做 API Gatway，但是没有解决这个问题

[ytmsdy]

从后端的角度来说，一个 API 的请求返回值如果过大的话，拆分成几个 API 是合理、正确、明智的。
API 的返回体过大几个弊端：
1：最直观的感受就是页面加载速度会下降，前端必须要等待所有的数据都返回以后才能显示。
2：如果并发量大的话，很容易造成业务的堵塞。
3：维护不方便
所以拆分出来是很合理的解决方案。

但是从前端的角度看
1：一个 API 拆分成多个 API 以后，打开一个页面需要发送多次请求，增加前端的工作量这是肯定的。
2：网络延时也是会增加，前端说对用户体验不好也是确实的。
3：乱七八糟的 API 多了以后，前端也头疼。

所以之前 amazon 有一篇专门的分享文章来说明他们是怎么来处理这些问题的，具体的你可以搜索一下。
LZ 也可以去了解一下 API 网关，这应该可以解决 LZ 的问题。

[ytmsdy]

@beneo 我找一下那篇文章。

[beneo]

@ytmsdy 感谢，api gateway amazon 真心不好找

[ytmsdy]

@beneo 关键词被淹没了~~

[ytmsdy]

@beneo 亚马逊的处理方法，大概是这样的。
1：后端把 API 拆分
2：通过 API 网关对 API 进行聚合形成一个新的 API 来返回多个 API 的聚合信息
3：对外只发布 API 网关聚合后的 API

[as463419014]

做一个组合查询的 api
先做分开做查询 api:get1(),get2(),get3(),get4()....
然后做一个组合查询 api:getx (args...),这个 api 就是根据参数中的值取查其他的 api 然后把查询结果组合起来一起返回

需要查 123 组合的结果,就调用 getx(1,2,3),需要 2,4 组合的结果,就调用 getx(2,4)
这样你可以愉快的按模块拆分 api,做 App 的也可以愉快的使用一个 api 获得查询结果了

以上内容纯属临时瞎编,考虑不周请见谅

[kalman03]

GraphQL

[artikle]

我们做法要是 API 返回信息过大过多，就考虑拆分为好几个接口，要么多次请求，要么只返回必须字段，另外的不是必须马上显示的信息可以延迟返回。
你的那种要是一次返回三个结构体的信息量不多，速度可以，请求不是特别频繁，就可以考虑组装一个新 model 返回。反之就拆分

[hotdogwc]

@kalman03 这个正解，但是有多少个公司可以做到全面使用呢？

[wc951]

微服务拆分肯定是每个 api 只负责自己那一摊，再通过 api gatway 之类的整合起来，有点像 esb 里的服务编排

[huijiewei]

restful 的指导意见是拆开

[Numbcoder]

这个问题明显是 App 开发想偷懒，API 拆分后，可以三个请求同时发起，如果 UI 没有关联的话，那么请求先完成的可以先显示，就算 UI 有关联，三个请求并发发起，肯定也比三个请求串联所花的时间短吧，明显是用户体验更好啊

[beneo]

@huijiewei 有文章么？这方面我也看了好几本书，但是没有遇到我说的那种情况，都是该怎么写，header 怎么写什么的

[TypeErrorNone]

我之前的做法是在用 openresty，做个组合接口的功能，后端提供的接口前端可以随意组合。

ps：这个功能在我离职后被我们牛逼的架构师拆掉了，呵呵

[beneo]

@TypeErrorNone 具体怎么弄呢？一般 API 是服务端提供，然后通过 openresty，有生成新的 API，这样好维护么？

[TypeErrorNone]

前端一次 post 多个接口地址，openresty 就是并发请求接口，组合接口内容，响应给前端。
这是代码 https://github.com/kangkang66/dockerlnmp/blob/openresty/nginx/lua/kang.lua

[pioneer]

哈哈哈