REST web应用程序中的分页

这是这个问题的一个更通用的重新表述(消除了Rails特定的部分)

我不确定如何在RESTful web应用程序中实现资源分页。 假设我有一个名为products的资源,你认为以下哪一个是最好的方法,为什么

1. 只使用查询字符串

< p >。http://application/products?page=2&sort_by=date&sort_how=asc 这里的问题是我不能使用整页缓存,而且URL不是很干净,很容易记住

2. 使用页面作为资源和查询字符串进行排序

< p >。http://application/products/page/2?sort_by=date&sort_how=asc 在这种情况下,我们看到的问题是http://application/products/pages/1不是唯一的资源,因为使用sort_by=price可以产生完全不同的结果而且我仍然不能使用页面缓存

3.使用页面作为资源,并使用URL段进行排序

< p >。http://application/products/by-date/page/2
我个人认为使用这种方法没有问题,但有人警告我这不是一个好方法(他没有给出原因,所以如果你知道为什么不推荐,请让我知道)

建议,意见,批评是非常欢迎的。谢谢。

64801 次浏览

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

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

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

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

我目前正在我的ASP中使用类似于此的方案。NET MVC应用程序:

例如http://application/products/by-date/page/2

具体来说,它是:http://application/products/Date/Ascending/3

但是,我并不喜欢以这种方式在路由中包括分页和排序信息。

项目列表(在本例中为产品)是可变的。也就是说,下次有人返回包含分页和排序参数的url时,他们得到的结果可能已经改变了。因此,http://application/products/Date/Ascending/3作为指向一个已定义的、不变的产品集的唯一url的想法就丢失了。

我同意Fionn的观点,但我将进一步说,对我来说,Page是资源,它是请求的属性。这使得我只选择选项1查询字符串。感觉很好。我真的很喜欢Twitter API的结构。不太简单,也不太复杂,有很好的文档。无论是好是坏,这是我的“go to”设计,当我在做某件事的一种方式和另一种方式之间犹豫不决时。

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

我倾向于同意slf的观点,即“页面”并不是真正的资源。另一方面,选项3更干净,更容易阅读,用户可以更容易地猜到,甚至在必要时输入。我在选项1和选项3之间犹豫不决,但没有任何理由不使用选项3。

另外,虽然它们看起来很好,但使用隐藏参数的一个缺点,而不是查询字符串或URL段,用户不能收藏或直接链接到特定的页面。根据应用程序的不同,这可能是问题,也可能不是问题,但只是需要注意的问题。

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

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

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

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

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

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

HTTP有很好的范围头,也适合分页。你可以发送

Range: pages=1

只有第一页。这可能会迫使您重新考虑什么是页面。也许客户想要不同范围的产品。Range头也可以用于声明订单:

Range: products-by-date=2009_03_27-

让所有的产品更新日期或

Range: products-by-date=0-2009_11_30

让所有的产品都比这个日期更老。'0'可能不是最好的解决方案,但RFC似乎想要一些范围开始。可能部署的HTTP解析器不会解析units=-range_end。

如果标题不是一个(可接受的)选项,我认为第一个解决方案(所有在查询字符串)是一种处理页面的方式。但是,请规范化查询字符串(按字母顺序排序(键=值)对)。这解决了“?a=1&b=x”和“?b=x&a=1”的微分问题。

奇怪的是,没有人指出选项3的参数是按特定顺序排列的。 http / /应用程序/产品/日期/降/名称/升/页面/ 2 而且 http / /应用程序/产品/名称/升/日期/降/页面/ 2 < / em >

指向相同的资源,但有完全不同的url。

对我来说,选项1似乎是最可接受的,因为它清楚地将“我想要的”“我想怎样”分开(它甚至在它们之间有问号,哈哈)。全页面缓存可以使用完整的URL实现(所有选项都会遇到相同的问题)。

使用参数在URL方法的唯一好处是干净的URL。尽管你必须想出一些方法来编码参数并无损地解码它们。当然,你可以使用URLencode/decode,但这将使url再次丑陋:)

我在我的项目中使用以下url:

http://application/products?page=2&sort=+field1-field2

意思是"给我第二页按field1升序,然后按field2降序"或者如果我需要更大的灵活性,我会使用:

http://application/products?skip=20&limit=20&sort=+field1-field2

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

抵消:用于集合中项目的索引。

限制:用于项目计数。

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

offset = offset + limit

下一页。

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

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

为了寻找最佳实践,我看到了这个网站:

http://www.restapitutorial.com

在参考资料页中有一个链接,可以下载一个.pdf文件,其中包含作者建议的完整REST最佳实践。其中有一节是关于分页的。

作者建议同时支持使用Range头和使用查询字符串参数。

请求

HTTP报头示例:

Range: items=0-24

查询字符串参数示例:

GET http://api.example.com/resources?offset=0&limit=25

其中抵消是开始项数,限制是要返回的最大项数。

响应

响应应该包括一个Content-Range报头,指示有多少项正在返回,以及总共有多少项尚待检索

HTTP报头示例:

Content-Range: items 0-24/66


Content-Range: items 40-65/*

在.pdf文件中,还有一些针对更具体情况的其他建议。

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

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