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

[firhome]

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

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

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

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

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

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

[wunonglin]

@hhjswf 这看你业务来着。我自己预想的是订单这个整体是一个服务

[shunia]

@chtcrack #61 光想后端逻辑没审需求吧，你说的技术基础是对的，如果说三个接口的展现分别在三个不同的地方或者都需要可以单独用来获取数据，你说的这种情况是有意义的，承载量的计算也没什么问题。
但是题主说的这里是一个界面同时需要这三份数据，那么你说的根本就是鬼扯，因为每个用户一进这个页面就是三个请求，刷新也是，那就不存在你说的问题，而且因为 http(s) 链接的特性，实际上还会消耗更多网络和服务器资源。
这里前端确实可以自行做聚合，难度也不高，虽然接口相互有依赖会延长请求时长降低总体请求的完成率，但是在当下的用户体验里可以做占位型展示，可以通过体验降低用户的失望。
不过所有从后端的角度说不应该分开的也完全是瞎说，总归是要根据业务需求实际处理，这个页面从题主目前的需求里看，属于可以前端聚合也可以后端聚合的情况，如果可以用到缓存的话其实更应该后端聚合。如果做后端真的只需要按表查询提供接口，那全都用 graphql 得了。

[lujiaosama]

token 过期了接口报错了然后前端去请求接口重新刷新 token 这是正常操作, 难道你想后端帮你刷新?接口顺便返回一个新 token 给你?这就不科学了.

[adoal]

graphql 就是为这种需求而来的

[rabbbit]

看了后面补的说明,我认为这个查订单状态这个聚合应该后端做.
毕竟后台订单管理详情一般都是要直接展示订单状态的,没人会点开订单详情然后再点个按钮查订单状态.
可以这样,以后提需求在群里 @他,所有交流都留记录.别明面上在有同事的时候跟他急眼,在试用期没过前找领导反应.

[rabbbit]

领导也不管的话,我建议代码和人有一个能那啥就行,你懂的.

[wdytoya]

作为后端同学来说一下我的想法，仅供讨论

其实你说的 12 两种方案都可以，我这都用过，具体用哪种方案取决于你具体的业务场景
1 方案的核心含义在于一次性返回全量数据，优势自然是减少前端请求次数，也相应减少多次网络上的开销，但劣势也很明显，因为你需要聚合完所有数据才能渲染，如果数据量较多，耗时较长，在用户 C 端上的体验就很糟糕，会有长时间的白屏，即便有些业务用 loading 态或者骨架图来兜底体验也不会好到哪去
2 方案的核心含义在于按需索取，优势在于你可以先渲染核心数据，非核心的数据增量渲染，特别是在一些动静分离的页面设计上是很有优势的。劣势自然就是增加了前端的请求次数，增加了网络开销和网络抖动可能导致的异常几率

而像楼主附言所说的两个页面，一个是订单列表页，一个是订单详情页
针对订单列表页，其实核心展示信息不多，主要是商品图标、商品名、订单 ID 、订单状态，其实是没必要返回商品全量信息的，所以如果按你们现在的方案 2 的设计去调一个批量接口或者分页接口是没毛病的
针对订单详情页，由于一般都是纯静态数据，而且用户不需要太多的行动点，这时候确实是可以一次性返回订单全量信息的，所以用类似于方案 1 的接口设计就会更合适

最后再说一下楼主说的刷 token ，这个楼主没理解为什么需要前端刷，其实楼主如果是 PC 时代过来的前端可能就不会很难理解了，一些文档编辑框页面的刷新就是一个经典的例子。因为页面是静态的，用户一直停留在页面上后端是不知道的，只有前端自己知道，而如果前端不去定期刷新状态，那么就会出现一种情况，用户在 token 过期之后在页面上执行了某个提交操作，结果由于 token 过期无法提交，可能在你第二时间才去做刷新操作之后，用户可能页面上填写的东西没保存下来就没了，那用户体验也是很糟糕的，当然有些做法是可以保存页面填写内容的，那为什么不直接就在过期的时候就提醒他要主动刷新了呢？
当然这里面还是可以说取决于你具体的业务场景，因此如果你们的产品对于第二时间再去做强制刷新觉得没有大问题，那也可以不用前端定期 refresh ，主要还是看第二时间的强制 refresh 会不会存在打断用户主流程的问题来决定

[xiangyuecn]

针对 商品、订单 两个东西的基础信息接口：
请求两个接口，前后端均合理。
请求三个接口，后端不合理。
请求一个接口，前后端均完全不合理。

[xiangyuecn]

至于 token ，后端应该是用的哪个全家桶，标准操作。只需前端对请求封装好了，不管是提前刷新也好重试刷新也好，完全可以做到上层代码无感知。

[Leviathann]

方式 2 大概能理解为什么
但是有个问题是这种方式中，如果列表的查询需要用订单或者 status 的字段做查询或者排序怎么搞

[Vitta]

你们后端是 java 吧

[leonme]

其实拆分的挺合理的

[ZSeptember]

RESTful API 就是这样的，很多逻辑在前端。后端只负责业务建模，不负责前端 UI 逻辑，因为业务逻辑不会经常改变，但是 UI 逻辑经常改变。
所以现在有 BFF 的架构，一般使用 GraphQL 做 BFF 中间层。

[dayeye2006199]

token 这个不要犟，token 过期属于常规操作；前端可以做一些封装，请求代码写起来就没区别了

[Samuelcc]

作为后端，我觉得订单信息和书籍信息拆开挺合理的。一个是数据量和分页的问题，一个是如果前端不同页面需要不同的数据后端都要写一个对应的聚合接口，会经常需要上线，代码难以维护，耦合严重，后续如果服务要进一步拆分就是兼容地狱。
分成多个接口也能一定程度避免单个微服务故障导致整个页面不可用的问题，前端可以异步请求显示，如果订单显示得慢也不耽误用户查看书籍信息。
对于比较复杂的业务，加个动态聚合层可能会更好。
不过也反思了下自己平时总是仅考虑后端的逻辑上要干净好维护，没怎么考虑前端的体验，可能前端也做得很痛苦。以后会多交流。

[lanbos]

刷 token 是必要的楼上的解释的很明白了。聚合层肯定得有，这种脏代码容易变化的部分肯定得有人做，无非是成本问题，小业务通常前端聚合成本最低，搞个中间层维护成本更高。。。。

[markgor]

有没有可能：
GET bookinfo-->缓存静态信息
GET bookOrderInfo --->缓存静态信息
POST bookorderInfostatus ---> 实时状态信息。
为了方便做数据缓存？

>token 登录态，如果快过期了，提供了个刷新 token 的接口给前端，喊前端发现 token 要过期了就去刷一下接口
这个我觉得没问题啊，你请求里的 token 过期了，你去刷新一下这个 token ，有什么问题呢？而且刷新后 token 值也不同了，后端也无法帮你替换成新的 token 值啊，而且这个你请求拦截时检查下不就好了？

[IvanLi127]

后端的问题，如果你们只分前端和后端，并且人手比例正常，后端是要 BFF 的。除非 bookinfo 只有二三十条，前端查询出来缓存用，不然肯定要后端关联查询的。

[IvanLi127]

token 过期，前端调完接口后发现过期，然后重新获取 token 。这个我个人认为没问题，有的时候是分 access token 和 refresh token 的。这样设计方便后续搞这个。

[24bit]

我们之前有类似的情况，拆分了微服务，然后又比较懒，直接在 rpc 服务上定义了前端需要的接口，通过网关做了协议转换。

后来是有一个聚合 http 服务来单独提供前端需要的接口。