比如一个“文章分类”的后端接口,一般都是要传pageNum和pageSize,但前端用一般要用全部的数据,但后端一般不会单独给一个拿全部数据的接口,这个一般是怎么处理的?
比如一个“文章分类”的后端接口,一般都是要传pageNum和pageSize,但前端用一般要用全部的数据,但后端一般不会单独给一个拿全部数据的接口,这个一般是怎么处理的?
看业务场景,如果是类似少量的下拉框码值数据支持全量返回的可根据情况约定pageSize为-1或者不超过指定数量的如999进行取值。同时后端接口需要同步加上pageSize限制,避免其他业务接口受影响拉取大量数据导致服务异常。
一般需要前端传一个较大的pageSize(上限能预估)。或者后端单独给一个接口获取全部数据(上限不确定的情况下)。
或者前端自动加载(循环请求所有页,不推荐),按需加载(用户滚动到底部自动加载,或者其它方式触发加载)
推荐做法:分页接口支持 all=true表示返回全部数据
在原有分页接口基础上,增加一个参数控制是否返回全部数据:
• 例如:GET /api/categories?
all=true
后端逻辑判断:
if (all === true) {
// 查询全部数据
} else {
// 按分页查询
}注意事项
数据量需可控(建议 < 1000 条)
后端建议加缓存(如 Redis)
不是吧,哥们,正常情况下如果一个接口有一处分页了,那整个系统都是要懒加载或者分页的,不然这个地方就会成为加载瓶颈,单看你的问题的话,看你的分页功能是怎么实现的了
PageHelper实现如果是PageHelper实现的,这个组件内部,如果pageSize是-1就是查询的全部(不分页),这个是由分页合理化控制的。
但这里有个潜在漏洞一些爬虫网站或者攻击人在调用接口时,通过-1就能拿到全部的数据了
这种你也可以通过固定的分页参数实现,例如page=0和pageSize=0,加上权限控制和接口防重放,越权等安全手段,都是通用方式
4 回答961 阅读
4 回答865 阅读
583 阅读
485 阅读
一般的临时解决方案就是给一个非常大的 PageSize 值,一般需要获取全部数据的业务场景都不会是大量数据的场景,所以一般临时解决就给一个 9999 就行了。
这个是按照需要使用到Item数据的情况。如果数据量比较大,那么就是做自动加载的逻辑,看情况来判断是否要做虚拟滚动。
如果只是需要拿 Total 值,那么直接从接口取 Total 值就行了,我们判断是否有下一页也是用的后端返回的 Total 值。直接取值就可以了,都不需要改 PageSize。
如果是需要获取各分类下面的文章数量,那么就需要后端开发一个接口来返回各个 Categroy 或者 Tags 下的数量。而不是前端拿全部的数据自己去汇总。
所以要看你是具体怎么样的一个业务。