请教后端同学这种写接口的方式对不对？

[firhome]

如：请求一本 book 的订单信息

[以前] 1.请求后端 bookinfo 接口，bookinfo 返回 data:{}, 包含了 book 的基本信息，book 的订单信息和订单状态(出售中，下架 等)

2.前端直接渲染数据即可。

[现在] 1.请求后端 bookinfo 接口 返回 book 基本信息 2.根据 bookinfo 接口获取 book 的 id ，再去请求 bookOrderInfo 获取订单信息 3.根据 book id 和 bookOrderInfo 里面订单 id ，再去请求个接口获取订单状态。

导致我初始化页面要发 3 个请求。

想问下 [现在] 这是个什么情况。是后端不愿意给我们包吗？喊他加数据感觉很艰难。很多东西得前端做。如果是这样的话，是不是后面前端可以写 node 来包一层？

[neptuno]

肯定不是懒，，懒的做法就是一个接口返回给你所有信息。订单状态不用单独接口，其他还行，就看业务有没有到这个程度了。

[neptuno]

如果都放一个接口，最终这个接口就会越加越多。最终就变成一个几万行 json 的接口（前公司现状）。导致 c 端用户体验极差。如果是 B 端，低频接口确实可以聚合，但最终都会拆分

[coreki]

现在基本都是 access token + refresh token ，access token 过期，前端刷新，获取新 token ，正常操作

[zhaomeicheng]

果然，全世界的后端...

[charlie21]

@chtcrack #62 睁眼说瞎话

[Gaays]

我这边也有遇到类似的情况，有多个接口而且是关联关系，想问一下大家如何处理网络请求问题，比如说网络中断，这里每个网络请求都用 try catch 来处理？多个接口多个 try catch ？因为不同接口阶段出现网络中断要报不一样的提示信息？这样处理合适吗

[WilliamYang]

我这里反对部分想偷懒的前端，总有些前端想要什么东西都一下子全塞进一个接口返回，直接渲染就好了

[expkzb]

放心，运维大哥会出来骂娘的。

[markgor]

@charlie21 #125 实际项目往往都会出现他说的那种场景；
一开始数据量小的时候，订单详情一个接口就把数据跑出来了，大家都方便。
数据量大了的时候，汇聚的接口返回 JSON 大小几百 KB ，开启 GZIP 的情况下，后端负载还算可以，但前端浏览器已经卡成狗了。
这个时候就需要拆分接口，先出列表，然后用户点开信息的时候，分开加载。
这种场景我遇到过两次，

一次是产品列表，
productList
|--spuList
|----skuList
开始的时候是分页返回 10 条 productList,里面汇聚了 spuList 和 skuList 的信息；
但对接某平台后，单个产品有几十个的 spu ，一个 spu 里有上百个 sku 。
浏览器直接崩溃，后来拆分接口，productList & spuList 汇聚 skuList 单独查询。

另一次是订单详情，
orderInfo
|--orderList
|----.....
|--personList
|---....
|--orderLog
|---....
|--payLog
|---....
|--.....
主订单包含一堆子订单，子订单关联不同的供应商，订单操作日志和财务信息等。
和上面一样，一开始都是把这堆信息打包到 JSON 里一次加载出来，
但实际使用后，由于 personList 和 orderList 是可以修改的，导致每次修改后都要重复载入，
最后只能才分开各自一个接口，哪一块操作后就加载哪一块的数据。
后期供应部分还对接的第三方平台，线上发单后的结果是异步返回的，所以针对供应状态也独立一个接口进行查询。

业务上线后，改动居多的都是前端部分，后端不可能因为“方便”前端，而把自己也“耗”进去吧。

[charlie21]

@markgor 你这个搞法也可以，只不过如果是按一个工程的工作量分配 `工程预算` 的话：后端预算 1000 ，前端预算 10000

[rabbbit]

@charlie21
事实就真跟他说的一样,往往后端都不会加接口,哪怕前端都忙疯了还要一堆接口 回调 try catch 人家照样天天喝茶.
正常,本来人加就没义务帮你, 所以我也准备转后端了,我也想喝茶当大爷.
dog

[rabbbit]

楼主这个算好的,我遇到的.
不给你批量删除的接口,让你自己写个 for 循环删.(调 100 次吗?)
让你提交订单, 完成订单 全走一个接口传订单状态编码的(客户端也走一个接口).

到底是谁懒呢?

[rabbbit]

反正我节后是准备 run 了,不伺候大爷.

[phxsuns]

需要有 BFF 。否则不仅前端处理起来麻烦，原子接口直接暴露可能还会有安全问题。

[handsomehaitao]

一二没毛病 bookinfo 为什么要返回你订单信息？ 三合并到二就可以了 刷新 token 你不处理让谁处理？

[markgor]

@charlie21 #130
这些没有对错，一脚踢的情况下怎么方便怎么来；
分前后端的话要么听架构的话，要么听项目经理的话，何必自寻苦恼；
我觉得 LZ 的公司职能是后端支配前端部门。

而且这些也很难说按工作量去计算。
据我所知微信小程序部门，一个人负责一个组件（比方 button/textarea ）或 api 。
可是他们的福利也比很多公司要好 :dog

[janus77]

微服务是针对服务端内部互相调用而做的，暴露给前端的话还是统一一个接口舒服。其实就是懒，少一个接口而已

[weakish]

订单状态也拆开应该就是 @markgor 在 117 楼说的订单状态是会变的，而订单信息基本是不变的。

后端拆细没问题（如果后面的服务确实是分开的话），前端写起来麻烦，但是好处是后端出故障的时候前端不会全挂。订单状态变动比较频繁，出问题的可能性最高，单独一个接口，那么它挂了，用户只是看不到订单状态或者看到的是可能过时的订单状态，其他功能都不影响。

另外，如果网站要保证离线可用（包括用户的流量非常贵，要尽可能省流量），前端是要自己缓存信息的。那么这种情况下，订单状态的缓存策略和订单信息和缓存策略应该是不一样的，这种情况下，后端接口分开，前端反而好处理。

[weakish]

@rabbbit 真正的不加接口是设计良好，该有的接口都有，足够正交，易于组合（让别人可以自己折腾）。虚假的不加接口，就是凑了一堆接口就结束了，反正又不是不能用（折腾别人）。

[lolizeppelin]

后端行不行我不知道
但 token 那个是标准做法
这都能 bb 说明你水平不行