json - 使用REST分页资源的正确方法是什么

Question

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

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

在响应正文中描述页面

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 header

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 header 来描述项目总数和总页数。

Answer 1

However, what if you changed the URL to be /foo/pages?page=1&count=3, now you are describing a page resource and not a foo resource.

REST 不关心您使用什么拼写作为标识符。

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

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

这两个标识符指向不同的资源；这些资源的响应主体(即表示)必须相同没有特殊原因。

除了RFC 5005 (它定义了您正在使用的链接关系)，您可能还想查看 Twitter timeline API 是如何工作的是设计出来的。