前端页面，一个页面几个接口请求比较合理？

Question

一个h5页面，刚进入该页面的时候请求几个接口拿到所有数据比较合理？

我现在的后端是一个区域一个接口，比如一个轮播图一个接口，一个小版块一个接口。有的区域还是相同的接口只是ajax传参不一样。一个页面刚进入可能需要一次请求七八个接口，而且有的接口一样只是传参不一样，请问这样合理吗？

Answer 1

这个考虑问题的角度我觉得不太对,抛开剂量谈毒性都是耍流氓,抛开时间谈数量一样也是耍流氓.
有的接口访问一下是毫秒级的,有的接口访问一下是秒级的.
我们考虑这个问题的时候必然是综合来看的,比如你说的同一个接口使用不同参数,这可能是一种良好的设计,也可能是一种很蠢的设计,没法一概而论.
比如说,首屏展示产品信息,分别展示不同类目的top3,设计成了访问N(类目数)次接口,每次返回单个类目的top(n),n是一个接口参数.
这个接口可能在首屏就请求了8次,前端说这太蠢了.但其实这样设计的接口更灵活,也许有一天运营说,现在我们要显示A产品8个,B产品5个,C产品去掉,前端动动手指就改了,如果后端接口聚合成一个呢?前端要改,后端也要改,后端改了之后,服务器可能还要停机发布,这就非常麻烦了,一般来说,H5的更新是成本最低的,所以后端底层一点,这种偏前端的逻辑就放在页面中也是合理的.
而且js作为异步的语言,区域独立ajax请求,反而可以先加载,先渲染,页面的体验反而会更好,也更方便做模块化.

如果需要获取的数据就是这么多,拆分请求和聚合请求,在时间上可以认为是聚合请求性能更好,这就和Edge和Chrome的对比一样,有说法是Edge其实比Chrome更快,但是Edge一定要等到资源下载完才开始加载,Chrome是边下载变加载的,显得反而比edge快.

另外呢,其实8个请求真的不多.

Answer 2

很多地方说页面性能优化 减少http请求 不知道你觉得你这样合理么?

Answer 3

我是赞成题主目前这种多次请求的，一般http都会设置keep-alive，因此多次请求，在时间上消耗并不大，并且还有好处是，页面首屏加载时间会更快。如果统一到一个接口，会增加以后的维护成本。

Answer 4

这个没有具体的数量去限制好吧，这要看项目情况，而且当多个接口合并在一起之后就导致接口的复杂度提升，将来不方便维护升级，拆开的太多又有接口请求过多的问题，所以你们要衡量好中间的取舍，这东西没有具体的限制

Answer 5

多个接口也没毛病，因为每个接口的功能不同。
但是相同的接口传参不一样,这个必须要后端合并优化。

Answer 6

你的想法应该首屏优化，而不是首页，首屏最好一个，其余的采用触发加载http请求。首页的请求可以是多个

Answer 7

一个页面刚进入可能需要一次请求七八个接口 ，个人觉得明显多了，对性能也有影响。个人建议，能合在一起的尽量就合在一个接口吧

Answer 8

最多4个，增删改查

Answer 9

看业务和数据库设计吧，当然越少越好，并且每个请求的耗时也越少越好。但是前端控制不了。如果请求太多，可以考虑将轮询之类的请求改为websocket，并对某些api进行本地缓存，加载页面时首先加载缓存的数据，然后再发送请求更新数据和缓存