一直困惑我的一个有分页列表的全部数据的接口问题?

比如一个“文章分类”的后端接口,一般都是要传pageNum和pageSize,但前端用一般要用全部的数据,但后端一般不会单独给一个拿全部数据的接口,这个一般是怎么处理的?

阅读 2.3k
10 个回答

一般的临时解决方案就是给一个非常大的 PageSize 值,一般需要获取全部数据的业务场景都不会是大量数据的场景,所以一般临时解决就给一个 9999 就行了。

这个是按照需要使用到Item数据的情况。如果数据量比较大,那么就是做自动加载的逻辑,看情况来判断是否要做虚拟滚动。


如果只是需要拿 Total 值,那么直接从接口取 Total 值就行了,我们判断是否有下一页也是用的后端返回的 Total 值。直接取值就可以了,都不需要改 PageSize。

如果是需要获取各分类下面的文章数量,那么就需要后端开发一个接口来返回各个 Categroy 或者 Tags 下的数量。而不是前端拿全部的数据自己去汇总。

所以要看你是具体怎么样的一个业务。

看业务场景,如果是类似少量的下拉框码值数据支持全量返回的可根据情况约定pageSize为-1或者不超过指定数量的如999进行取值。同时后端接口需要同步加上pageSize限制,避免其他业务接口受影响拉取大量数据导致服务异常。

一般需要前端传一个较大的pageSize(上限能预估)。或者后端单独给一个接口获取全部数据(上限不确定的情况下)。

或者前端自动加载(循环请求所有页,不推荐),按需加载(用户滚动到底部自动加载,或者其它方式触发加载)

数据量特别大(过万了)建议前端开启滚动加载不断请求对应接口,如果确定数据量不会特别大建议后端额外搞一个全量的接口或者前端直接传{pageSize: 9999},

推荐做法:分页接口支持 all=true表示返回全部数据

在原有分页接口基础上,增加一个参数控制是否返回全部数据:
• 例如:GET /api/categories?
all=true
后端逻辑判断:

if (all === true) {
  // 查询全部数据
} else {
  // 按分页查询
}

注意事项
数据量需可控(建议 < 1000 条)
后端建议加缓存(如 Redis)

新手上路,请多包涵

如果你非要在一个接口实现,不考虑数据量巨大的问题,你和后端协商好,不传参默认查询全部就行了,有分页参数则按照分页返回

不是吧,哥们,正常情况下如果一个接口有一处分页了,那整个系统都是要懒加载或者分页的,不然这个地方就会成为加载瓶颈,单看你的问题的话,看你的分页功能是怎么实现的了

PageHelper实现

如果是PageHelper实现的,这个组件内部,如果pageSize-1就是查询的全部(不分页),这个是由分页合理化控制的。
但这里有个潜在漏洞一些爬虫网站或者攻击人在调用接口时,通过-1就能拿到全部的数据了

自定义分页实现

这种你也可以通过固定的分页参数实现,例如page=0pageSize=0,加上权限控制和接口防重放,越权等安全手段,都是通用方式

新手上路,请多包涵

类似"文章分类"这种数据通常是字典值,数据量通常不会太大,可以单独写一个全部数据的接口,或者pageSize传大一些。如果这种类别数据太大,那可能是设计的有问题了。

拿全部数据干什么?做分析么?不应该是后端给一个分析结果的接口么?

展示用吗?1万多条数据展示的完吗?不应该是做瀑布流吗,鼠标滚到最后几条再加载更多的。

如果分类少的话,可以返回全部,
数据量多的话,建议 前端做一个下拉加载 或者滚动加载就好了
数据量多全部返回的话,会影响页面加载的性能,接口响应的时间比较长,对用户体验不好