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

[firhome]

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

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

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

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

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

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

[leafre]

oauth2.0 token 就是这样处理，除非不用 token

[byte10]

这问题其实非常的好，其实在架构设计的时候 ，就有这个方案的选型，不管怎么样，后端肯定是需要一个数据聚合层的，因为你的这个多次查询的方案，前端体验非常的糟糕。现在就是这个聚合的逻辑放在前端还是后端的问题，其实都没有错，但是更多的是放在后端，最好统一放在后端，架构统一。放在前端其实不太好控制，尤其是 app 的发版，如果是 WEB 倒无所谓了。

[winglight2016]

接口设计，当业务体量小的时候，怎么搞都没问题。既然是看一本书的相关订单，那就是后台应用，没有并发压力，设计方案基本上靠 PK 解决。

token 设计并没有问题，只是不应该前端判断“快”到期了就去刷新一下，而是 accesstoken 失效后，前端处理这个返回异常时，再用 refreshtoken 刷新一下，可以获得 accesstoken 。虽然我也觉得这么搞很麻烦，可是设计上把 accesstoken 的过期时间设置的短一些，是为了提高安全性。

[lblblong]

这种情况我一般就把后端的三个接口包装一下，反正也多不了几行代码，公司的业务，加载快不快你管它干嘛，有人要问为什么这么慢，你就直接甩锅给后端说接口拆太多了呗

[anc95]

BFF 中间层搞起，加上前后端一体化调用，体验蹭蹭的上去了。中间层部署、前端脚手架再整点基建，可以升职加薪了，多好

[SmiteChow]

无所谓对错，权责而已。要么大前端，要么小前端，看人员配比。

大前端就上 graphQL ，小前端就求后端加接口。

[xrsylf]

刷新 token 这个方式现在就算不是主流，应该也是普遍使用了

[leafre]

本着谁受益谁研发原则，API 聚合(BFF)应该由前端团队研发，毕竟想要什么数据，前端自己最清楚，BFF 也减轻了前后端的沟通成本

[giiiiiithub]

聚合谁来做的问题，后端懒得做让前端做了。这后端有点懒了，api gateway 其职责之一就是组合内部服务 api 对 client 提供服务。

[4771314]

不了解具体的业务场景，但是这就是一个数据聚合的问题。
看你们的具体模型和架构是怎样的，一般就两种：有 BFF 、没有 BFF ，有 BFF （一般是前端团队维护）的话，这部分的逻辑放到 BFF 中实现是合理的；如果是没有 BFF 这个分层，那么这份数据一般还是后端聚合，毕竟这里要是前端实现的话，接口是串行的，会影响前端页面的渲染，不是很合理。
不过如果项目就是常见的前端-后端模型的话，那就应该打死后端（虽然我是后端 QAQ ），毕竟在这种场景中，后端是为前端服务的，如果前端的需求就是聚合后的数据，那后端需要提供聚合后的数据的。

[4771314]

token 的问题是不是登录态就解决了
token 过期的时候，提醒用户重新登录，这也是很常见的操作了吧？

[Mrzhs]

说白了就懒呗.一个数据对应后端不同的表,不愿做数据聚合

[rickiey]

很明显，数据量太小，连分页都没有，体量不大的小公司吧，随便搞搞了，想咋弄就咋弄，出不了啥大问题，屎山上堆屎就行了，人一定要看开点

[lufer]

@lblblong
这种情况我一般就把后端的三个接口聚合一下，反正也多不了几行代码，公司的业务，加载快不快你管它干嘛，老板要问为什么前端数据渲染这么慢，你就直接甩锅给前端说接口全聚合了呗