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

[firhome]

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

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

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

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

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

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

[lqu3j]

2 是订单摘要信息，3 是订单详情的话我觉得很正常，没毛病，只是一个状态的话就完全没必要了， 至于 1,2 既然是订单,就算体量不大，短时间不需要分页，时间长了，肯定有分页逻辑，我觉得没毛病，总体上来说站后端.

[jessun1990]

个人想法：

1 、2 拆分开没有问题。2 、3 可以考虑合并。

[preach]

GraphQL 的逻辑，大概率是后续用 GraphQL ，应该是挺牛逼的后端，只是没和你说他的想法

[keppelfei]

如果是同一个页面，不建议做三次请求，三次 http 握手挺费劲的，如果是微服务可以考虑用中间件来解决状态问题。

对于这种情况可以在弱网情况下展示给后端看看，这样做体验太差了

[pengtdyd]

不是挺好的嘛，你看分多清楚

[cr217]

体现前端价值的时候来了，用 node 写个 bff 中间层。述职时又有东西说了

[labulaka521]

最起码数据要一起返回吧，

[linglin0924]

我没大看懂楼主的描述 。以前的接口划分：为啥 bookinfo 和 bookOrderInfo 混在一起返回 ？

一个是书籍信息，一个是订单信息，这是两回事吧，不就得拆出来两个接口，为啥要在一个 bookinfo 里返回。

订单状态 也可以单独分出来一个接口。第二种划分业务不是更清晰么？业务接口划分细一点，颗粒小好控制，按需请求。



按照以前的接口

加入商城页面需要获取书籍信息，直接请求 bookinfo 接口，返回的订单信息和订单状态扔掉？

[linglin0924]

我还没搞不懂，为啥要从 bookinfo 接口返回订单信息和订单状态。

[flighter]

这个后端要么懒要么菜，只知道数据拆分微服务，却不知道跟随微服务的业务聚合层，这一层是直接和前端对接的

[linglin0924]

我还没搞懂，为啥要从 bookinfo 接口返回订单信息和订单状态。

[wunonglin]

@linglin0924 #89

我认为是因为 lz 习惯了 bookinfo 一股脑带出来可以直接渲染，页面不用太多异步逻辑，加上以前单服务的时候是可以 join 起来也方便，所以直接返回也没什么问题。这是 ok 的，因为那时候大家都这么做的。

但是到现在新微服务架构后，两个服务分开了，分别提供了 curd ，就没必要再加一个聚合的 bookinfo 接口，因为确实没必要。

这个构架不用考虑握手太多的问题。人少对系统没压力，人多接口分细了反而能降低系统负载，前端也可以用中间件做 ttl 缓存。问题很好解决，或者说压根不是问题。

时代变了呀~

[wu00]

微服务架构，我们公司现在也这样; 只不过我们对 C 端的接口还是进行了 bff 聚合，B 端(管理后台)的接口也是让前端去请求 N 个接口自己去拼...
后端追求解耦、分治，前端追求减少 http 请求，都有道理，bff 层很多大公司都有专门的“服务于前端的后端”开发人员，遵循服务自治，谁使用谁开发的原则，这东西就应该前端来写。小公司后端来写，毕竟聚合各接口都得走内网，发布部署都不能跟后端分离。
后端同事"笑话"你们成了面向微服务的前端，说明他们是知道这个问题的存在的。

[hhjswf]

@wunonglin 显然不是阿，订单信息跟订单状态不是一个服务？这也要拆？这个后端是多少沾点没得洗

[cnbattle]

所以 订单服务里 不用做商品信息 snapshot 吗 ? 有点迷，后端 sb ，拿微服务的噱头偷懒

[gadfly3173]

刷新 token 很常见啊，一般是 access+refresh ，act 过期就用 refresh 刷新，拿到一个新的 token 。除非你们 token 刷新之后不变，否则这个设计非常合理。难道每个接口都要预留给你下发新 token 的位置么？

[jeeyong]

@wangkun025 菜鸡不应该是更简单得思维吗? 一个接口做所有...
比如, 我做个接口, 你可以直接发 sql 指令, 接口去执行返回结果..哈哈哈哈
看起来像微服务得思维啊..全解耦...

[learnshare]

后端：你看我 微服务、细粒度、业务无关、易于维护、一看就懂
前端：接口要面向业务，不写滚蛋

主要问题是没人把关，各玩各的，互骂傻*
实际上怎么写都行，但一定要达成一致
招人写中间层也行，打死后端也行，折磨前端也可以

从前端 /客户端角度讲，应该尽量避免这种链式请求
几个链式请求的时间和连续几个数据库查询的时间可能相差几百 ms ，甚至几秒

[vance123]

总要有代码去处理聚合的，不是你写就是他写

[wangkun025]

@jeeyong 有道理啊😮