使用 REST 分页资源的正确方法是什么答案

【问题标题】：What is the Correct Method of Paging Resources using REST使用 REST 分页资源的正确方法是什么
【发布时间】：2018-08-16 20:00:10
【问题描述】：

下面有两个示例，展示了使用 REST 进行分页的两个相互竞争的实现。哪个更“正确”？

在以下两种情况下，我都使用标准的Link HTTP 标头将 URL 添加到下一页、上一页、第一页和最后一页。

在响应正文中描述页面

GET /foo?page=1&count=3

Content-Type: application/json
Link: </foo?Page=2&Count=3>; rel="next", </foo?Page=1&Count=3>; rel="first", </foo?Page=2&Count=3>; rel="last" 
{
  "page": 1,
  "count": 3,
  "totalCount": 9,
  "totalPages": 2,
  "items": [
    { "item": 1 },
    { "item": 2 },
    { "item": 3 }
  ]
}

我听说这不是 REST'ful，因为它改变了资源响应体。但是，如果您将 URL 更改为 /foo/pages?page=1&count=3，现在您描述的是 page 资源而不是 foo 资源。

链接和 X-Pagination HTTP 标头

GET /foo?page=1&count=3

Content-Type: application/json
Link: </foo?Page=2&Count=3>; rel="next", </foo?Page=1&Count=3>; rel="first", </foo?Page=2&Count=3>; rel="last" 
X-Pagination: { "page": 1, "count": 3, "totalCount": 9, "totalPages": 3 }
[
  { "item": 1 },
  { "item": 2 },
  { "item": 3 }
]

使用这种方法意味着响应正文没有改变，但是我使用了一个非标准的 HTTP 标头来描述项目总数和总页数。

【问题讨论】：

我真的很想知道你为什么需要通过 REST 来解决这个问题。分页应该是管理客户端。我建议以您可以提交“开始”和“限制”参数的方式构建您的 REST-GET，它不需要了解任何关于页面的信息。
我肯定会选择第一个选项并且总是有一个"items" 键。
@Ryan Care 详细说明为什么？

标签： json rest http http-headers restful-architecture

【解决方案1】：

但是，如果您将 URL 更改为 /foo/pages?page=1&count=3，那么现在您描述的是页面资源而不是 foo 资源。

REST 不在乎您对标识符使用什么拼写。

但是，它确实将不同的标识符映射到不同的资源。也就是说

/foo
/foo?page=1&count=3

这两个标识符指向不同的资源；这些资源的响应主体（即表示）不需要相同，没有什么特别的原因。

除了RFC 5005（定义您正在使用的链接关系）之外，您可能还想了解Twitter timeline API 的设计方式。

【讨论】：

【解决方案2】：

我猜他们都还好。这取决于您如何定义访问的资源。

如果您定义访问页面资源，您的第一个示例将是正确的。（假设不定义页面属性会导致默认页面）
如果您定义使用分页表示，你的第二个例子是正确的。这将走向内容协商的方向。

我建议您选择最适合的套件。我个人倾向于举一个例子，因为它更易于使用且更直观

REST 只是一种架构。它可以通过多种方式实现，具体取决于定义。没有一个正确的解决方案。

我听说这不是 RESTfull，因为它改变了资源响应正文。

内容协商是更改资源表示的有效方式。（这会改变响应对象而不是资源本身）

【讨论】：