RESTful 设计：分页集合答案

【问题标题】：RESTful Design: Paging CollectionsRESTful 设计：分页集合
【发布时间】：2010-10-04 19:12:54
【问题描述】：

我正在设计一个 REST api，它需要从服务器端强制执行分页（每 x）。

浏览任何资源集合的正确方法是什么：

选项 1：

GET /resource/page/<pagenr>
GET /resource/tags/<tag1>,<tag2>/page/<pagenr>
GET /resource/search/<query>/page/<pagenr>

选项 2：

GET /resource/?page=<pagenr>
GET /resource/tags/<tag1>,<tag2>?page=<pagenr>
GET /resource/search/<query>?page=<pagenr>

如果是 1，我应该如何处理 GET /resource？重定向到/resource/page/0，回复一些错误或回复与/resource/page/0完全相同而不重定向？

【问题讨论】：

【解决方案1】：

由于我对 REST 的理解有限，那么以下内容可能是“最”宁静的。

GET /resource/?page=<pageenr>&asof=<datetime>

由于表示的内容永远不会发生意外变化，因此可以使用缓存。

但要真正回答你的问题，我认为参数页面是首选方法。

【讨论】：

不仅如此，分页也不是资源的一部分。无论您是否使用分页，以及以何种形式，都不会改变资源，只是您要求查看它的方式。排序顺序，甚至过滤也是如此。
@Dave Van den Eynde：那是错误的。 RFC 3986（URI 通用语法）状态（第 3.4 节）：“查询组件包含非分层数据， 连同路径组件中的数据（第 3.3 节）， 用于标识资源 在 URI 的方案和命名权限（如果有）范围内”（我的突出显示）。第二页是与第一页不同的资源。但无论如何，它与 RESTfulness 无关。
根据该 RFC，URI 的“片段”部分应该用于分页/排序。但我严重怀疑此 RFC 是否适用于此。你试过这个吗？我认为浏览器不会区分只有片段不同的两个 URI。也许我应该换个说法。如果在 REST api 中，“资源”确实是由 PATH 标识的，那么 QUERY 可用于通过分页/排序来完成资源。但是对于 REST，什么是“资源”，不同于 URI 上下文中的资源。

【解决方案2】：

我会选择选项 (2)。为什么？

【讨论】：

【解决方案3】：

URI 的样子并不是最重要的部分。相反，您应该考虑的是它是如何呈现给用户的。例如，一个页面应该有一个指向“下一个”页面的链接和另一个指向“上一个”页面的链接（如果有的话）。看看RFC 5005 Feed Paging and Archiving

【讨论】：