在实现一个带有分页参数的Rest API时,应该从零开始索引还是从1开始。这些参数将是Page和PageSize。
对我来说,从1开始更有意义,因为我们谈论的是页数。
在实现一个带有分页参数的Rest API时,应该从零开始索引还是从1开始。这些参数将是Page和PageSize。
对我来说,从1开始更有意义,因为我们谈论的是页数。
目前没有标准规定。只需查看一下:有数十万个API采用不同的方法。
我所知道的大多数API使用以下分页方法之一:
offset
和limit
或page
和size
两者都可以是0
或1
索引。哪个更好?这取决于你自己。
只需选择适合您需要的方法,并妥善记录它。
此外,您可以在响应有效负载中提供一些链接,以使页面间导航更加容易。
例如,考虑您正在从第2页读取数据。因此,为上一页(第1页)和下一页(第3页)提供链接:
{
"data": [
...
],
"paging": {
"previous": "http://api.example.com/foo?page=1&size=10",
"next": "http://api.example.com/foo?page=3&size=10"
}
}
记住,始终要创建一个 你自己 会喜欢使用的 API。
确实,这方面没有标准。
我发现微软的产品(如Visual Basic 6、Visual C++ 6等旧版本的DAO)通常以1作为起始页码,但许多其他技术堆栈使用0。逐渐地,我发现越来越多的库开始使用0而不是1。
为什么呢?因为从数学上讲,将pageIndex从0开始映射到DB或数组中的rowNumber更容易。假设您从数据库中获取了一个包含100个记录的数据集。现在您想要发送第二页(例如pageSize=10)。如果pageIndex从0开始,那么您只需要编写:
startRowNumber = pageIndex * pageSize;
return dataSet[startRowNumber, startRowNumber + pageSize]
因为在大多数数据库和编程语言中,数组/列表的索引从0开始。即使你的Rest API使用了1索引数组,当映射1索引的页码到记录ID时仍然会有问题。例如:假设你有一个数据集,索引为1..100(而不是0..99),并且你想发送第11到20条记录作为第二页(这里pageSize=10,pageIndex=2,因为你的起始索引为1)。这意味着你需要使用以下公式:
((pageIndex - 1) * pageSize) + 1 ; // to get the number 11.
对于开发人员来说,0索引分页更容易处理。
对于人类用户来说,1索引分页更有意义,因为我们计数时从1开始。