没有官方模式,任何选择都取决于您的数据大小。
无论您做什么,请始终对您将返回的项目数量设置最大限制,而不管客户端在请求中提供的参数如何。
另外,创建一个默认计数,以便在参数未提供任何信息时返回。
如果您没有大量要退回的物品,您可以将 默认计数 设置为 最大限制,这足以始终退回所有物品,您可以只需将没有任何具体计数详细信息的 url 全部返回即可。
GET /products (no count/provided)
如果您有数百或数千并且您的 默认计数 为 100,则可以使用明确的 count 来扩展该限制(当然可以达到最大值 - 如果要求count > max,返回 400 错误请求,消息指示 count 不能高于 max)
GET /products?count=1000000
但是,如果您不断将最大限制推得越来越高,这对您的服务器和/或客户端来说可能会很糟糕。
通常,如果您有很多记录,则将其分块并使用计数和偏移量将其拉入字节大小的块中。还将元数据添加到响应对象,让请求者知道当前位置、总记录和提供的偏移量
一点伪代码:
$count = 1000
$offset = 0
While count*offset < total records:
GET /products?count=$count&offset=$offset
$offset = $offset + $count
假设其中一个请求如下所示:
GET /products?count=1000&offset=1000
然后在响应正文中,您会期望类似:
{
"result": [
{
"id": "123",
"name": "some product",
"link": "/product/123"
},
... many more products ...
{
"id": "465",
"name": "another product",
"link": "/product/465"
}
],
"meta": {
"count": 1000,
"offset": 1000,
"total_count": 3000,
"next_link": "/products?count=1000&offset=2000",
"prev_link": "/products?count=1000&offset=0",
},
"status": 200
}
如果你真的想要金星,你可以让你的资源遵守 HATEOS (https://en.wikipedia.org/wiki/HATEOAS) 并在列表中包含指向各个资源的链接,如果你在元数据中可能有指向列表中下一个和前一个块的链接'正在走一大串项目。我在上面的 json 示例中放置了一些示例链接。