我认为版本3的问题更多的是一个“观点”问题——你把页面看作资源还是页面上的产品。

如果将页面视为资源，这是一个完美的解决方案，因为对第2页的查询总是会返回第2页。

但是，如果您将页面上的产品视为资源，那么第2页上的产品可能会发生变化(旧产品被删除或其他)，在这种情况下，URI并不总是如此 返回相同的资源。

例如，客户存储了一个到产品列表X页的链接，下次该链接被打开时，问题产品可能不再在X页。

我使用in下面的模式来获得下一页记录。 http://application/products?lastRecordKey=?&pageSize=20&sort=ASC

RecordKey是数据库中保存顺序值的表的列。这用于一次只从DB中获取一个页面数据。 pageSize用于确定获取多少条记录。Sort用于按升序或降序对记录进行排序。

我一直使用选项1的风格。在我的例子中，缓存并不是一个问题，因为数据经常变化。如果您允许页面的大小是可配置的，那么数据就不能被缓存。

我不觉得url难记或不干净。对我来说，这是查询参数的一个很好的使用。资源显然是一个产品列表，查询参数只是告诉您希望如何显示该列表—排序和哪个页面。

我更喜欢使用查询参数offset和limit。

偏移量:用于集合中项目的索引。

限制:为项目的数量。

客户端可以简单地继续更新偏移量，如下所示

offset = offset + limit

下一页。

路径被认为是资源标识符。页面不是资源，而是资源集合的子集。由于分页通常是一个GET请求，因此查询参数最适合用于分页，而不是用于标头。

参考:https://metamug.com/article/rest-api-developers-dilemma.html # Requesting-the-next-page

选项1似乎是最好的，因为您的应用程序将分页视为一种为同一资源生成不同视图的技术。

尽管如此，URL方案相对来说并不重要。如果将应用程序设计为超文本驱动的(根据定义，所有REST应用程序都必须是超文本驱动的)，那么客户端将不会自行构造任何uri。相反，您的应用程序将向客户端提供链接，客户端将遵循这些链接。

客户端可以提供的一种链接是分页链接。

所有这些令人愉快的副作用是，即使您改变了对分页URI结构的想法，并在下周实现了完全不同的东西，您的客户机也可以继续工作，而无需进行任何修改。

我以前用过解决方案3(我写了很多django应用程序)。我不认为这有什么问题。它就像其他两个一样可生成(以防你需要做一些大规模的刮擦或类似的事情)，它看起来更干净。另外，你的用户可以猜网址(如果它是一个面向公众的应用程序)，人们喜欢能够直接去他们想去的地方，猜网址感觉很强大。