本文讨论了分页API设计中的常见问题，包括根据item_id分页和常规分页方式的优缺点。提出了结合since_id和max_id来处理数据变动带来的影响，并强调服务端决定分页策略以适应不同业务场景的重要性。最后总结，没有万能的分页方案，需针对具体业务设计弹性API。
常规的分页方式
API处理分页看似简单，实际上暗藏危机。最常见的分页方式，大概是下面这样的
/users/?page=1&limit=5
//服务端返回
最理想的情况下，客户端请求第一页的5条数据，服务端如常返回，比如下图:
拿Twitter的图用一下，假设我们的数据库有10条数据，按照5条一页，正好有2页。
在理想情况下，客户端拉取数据时不会出现任何异常。但，这仅仅是正常情况,如果此时刚好有2条新数据插入。
数据库记录变为13。原来第二页的数据是[5, 4, 3, 2, 1]，现在变为[7, 6, 5, 4, 3]，我们再一次拿到了第一页的数据。同理，如果用户在拉取数据时正好有数据被删除，一样会出现类似的问题。
根据item_id分页
要解决此类问题
最低0.47元/天 解锁文章
2768
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
