使用REST

Question

下面有两个示例，显示了使用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，因为它改变了资源响应体。但是，如果您将网址更改为/foo/pages?page=1&count=3，那么现在您要描述的是page资源，而不是foo资源。

链接＆amp; 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标头来描述项目总数和总页数。

Answer 1

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

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

我建议您尽量选择最适合自己的套房。我个人倾向于举例，因为它更容易使用，而且更直观

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

  

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

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

Answer 2

  

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

REST并不关心您用于标识符的拼写。

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

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

这两个标识符指向不同的资源;没有特别的理由说这些资源的响应主体（即代表）需要相同。

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