前端调用后端接口时，是后端一次性把所有数据封装好发给前端，还是分开请求不同的接口比较好？

[proletarius]

[wolfie]

单页面初始化请求过多，可以额外出一个封装多个接口的请求。

[bigbigpark]

一次性把所有数据封装好会不会导致接口响应过长，页面没有数据可展示

[learnshare]

具体问题具体分析，缺少细节没办法讲合适的方案

[kop1989]

楼主问的这个问题太大了，涉及到过多的情况。
以下只是泛泛的聊一下，如果有既定场景，可以继续再深入探讨。

如果完全面向前端设计接口：

1 、会导致接口的复用性极度降低。
2 、会降低前端处理数据的灵活性。（并不是所有接口都会依赖前一个接口的结果）
3 、因 2 、会衍生性能问题（本来可以并发的请求，因为接口的合并，导致不能并发）。
4 、影响异常时的影响范围（接口颗粒度越细，则每个接口出错时对界面的影响越小）。

[wanguorui123]

不考虑延迟情况下，分开最好

[heiheidewo]

分开请求比较好，开启了 keep-alive 可以节省一些资源吧

[Vegetable]

出门是带一张 100 元的好还是 100 张 1 块的好呢？

这东西不能一概而论。

[thtznet]

看页面的设计，复用率等综合考虑，没有银弹。

[imnpc]

都是根据需求来的 例如
APP 首页 元素不多可以一次给出
多的话需要分多个接口多次请求
大部分列表页一次性给出即可
商品页 /订单流程可能需要多个接口按需调用

[InDom]

请把查询量最大的接口给我，有人回帮你们天天压测的。

[shellus]

@InDom 给你 10 个小的接口你也可以压测啊

[MrZhaoyx]

graphQL

[kaneg]

最近在搞后端 API 的聚合，也有楼主一样的纠结。如果分多个 API，UI 写的代码就比较，维护起来也麻烦；如果全放后端，又会降低灵活性。

不过多个调用能并发的，前端和后端都能做。

[intmax2147483647]

没看到楼上有提到比较好的实践，如果前端面对的是多个 server，那么最好是有个 BFF （ Backend frontend forwarder ）. 将后端 API 做聚合，直接返回前端组件能后直接使用的数据。

[RealJacob]

如果数据量不多当然可以一次请求。
但是根据领域驱动设计的原则，对前端来说，肯定是不同领域对应不同接口在开发的时候更清晰合理，跨领域使用数据是该避免的事情。实际开发中，哪些接口该并发，哪些需要优先请求，fcp 是否可以优化，都是不能一概而论的。

[bsg1992]

这个得看页面不能一概而论。
UI 数据需要一次性全部展示，我建议的是后端做一个聚合接口。
UI 可以对数据进行分段展示就不需要 做聚合接口。
这种问题 不单单是 前端和后端的问题，还得问问设计师。