Question

我正在为我正在处理的移动应用程序设计RESTful API。我的问题是包含许多项目的大型集合。我知道一个好的做法是在集合中对大量结果进行分页。

我已阅读Facebook Graph API文档（https://developers.facebook.com/docs/graph-api/using-graph-api/v2.2），Twitter游标文档（https://dev.twitter.com/overview/api/cursoring），GitHub API文档（https://developer.github.com/v3/）和此帖（API pagination best practices）

考虑我的API中的示例集合/resources，其中包含100个名为resource1到resource100的项目，并按降序排序。这是您在GET请求（GET http://api.path.com/resources?limit=5）上得到的回复：

{
    "_links": {
        "self": { "href": "/resources?limit=5&page=1" },
        "last": { "href": "/resources?limit=5&page=7" },
        "next": { "href": "/resources?limit=5&page=2" }
    },

    "_embedded": {
        "records": [ 
            { resource 100 },
            { resource 99 },
            { resource 98 },
            { resource 97 },
            { resource 96 }
        ]
    }
}

现在我的问题是这样的场景：

1- I GET /resources以上内容。

2-之后，会在资源集合中添加一些内容（例如，另一台设备会为此帐户添加新资源）。所以现在我有101个资源。

3- I GET /resources?limit=5&page=2因为初始回复建议将包含我的结果的下一页。答案如下：

{
    "_links": {
        "self": { "href": "/history?page=2&limit=5" },
        "last": { "href": "/history?page=7&limit=5" },
        "next": { "href": "/history?page=3&limit=5" }
    },

    "_embedded": {
        "records": [ 
            { resource 96 },
            { resource 95 },
            { resource 94 },
            { resource 93 },
            { resource 92 }
        ]
    }
}

正如您所看到的，resource 96在两个页面中都重复出现（如果在步骤2中删除了资源，则可能会出现类似问题，在这种情况下，一个资源将会丢失）。

由于我想在移动应用程序和一个列表中使用它，我必须将每个API调用的资源附加到它之前的那个，这样我就可以有一个完整的列表。但这令人不安。如果您有任何建议，请告诉我。提前谢谢。

P.S：我已经考虑过像查询字符串这样的时间戳而不是基于光标的分页，但这会给我带来问题。（如果您需要更多相关信息，请与我们联系。）

Answer 1

我们刚刚通过REST API为移动应用程序实现了类似的功能。移动应用程序传递了一个额外的查询参数，该参数表示页面中的元素应该被冻结的时间戳＆＃34;。

因此，您的第一个请求看起来像GET /resources?limit=5&page=1&from=2015-01-25T05:10:31.000Z，然后第二个页面请求（稍后一段时间）会增加页数但保持相同的时间戳：GET /resources?limit=5&page=2&from=2015-01-25T05:10:31.000Z

这也为移动应用程序控制是否要区分＆＃34;软＆＃34;页面（保留第1页请求的时间戳）来自＆＃34;硬刷新＆＃34; page（将时间戳重置为当前时间）。

Answer 2

为什么不保留一组看到过的资源？

然后，当您处理每个响应时，您可以检查资源是否已经显示。

RESTful API设计中的分页问题

2 个答案: