我对此进行了长时间的思考，最终得出了下面我将描述的解决方案。这在复杂性上是一个相当大的进步，但如果你确实迈出了这一步，你最终会得到你真正想要的，这是未来请求的确定性结果。

你所举的项目被删除的例子只是冰山一角。如果您正在通过颜色=蓝色进行过滤，但有人在请求之间更改了项目的颜色，该怎么办?以分页方式可靠地获取所有项目是不可能的…除非…我们实现修订历史。

我已经实现了它，实际上它比我想象的要简单。以下是我所做的:

I created a single table changelogs with an auto-increment ID column My entities have an id field, but this is not the primary key The entities have a changeId field which is both the primary key as well as a foreign key to changelogs. Whenever a user creates, updates or deletes a record, the system inserts a new record in changelogs, grabs the id and assigns it to a new version of the entity, which it then inserts in the DB My queries select the maximum changeId (grouped by id) and self-join that to get the most recent versions of all records. Filters are applied to the most recent records A state field keeps track of whether an item is deleted The max changeId is returned to the client and added as a query parameter in subsequent requests Because only new changes are created, every single changeId represents a unique snapshot of the underlying data at the moment the change was created. This means that you can cache the results of requests that have the parameter changeId in them forever. The results will never expire because they will never change. This also opens up exciting feature such as rollback / revert, synching client cache etc. Any features that benefit from change history.

分页通常是一个“用户”操作，为了防止计算机和人脑的过载，通常会给出一个子集。然而，与其认为我们没有得到完整的列表，不如问问它重要吗?

如果需要一个精确的实时滚动视图，本质上是请求/响应的REST api并不适合这个目的。为此，你应该考虑WebSockets或HTML5 Server-Sent Events，让你的前端知道何时处理更改。

现在，如果需要获得数据的快照，我将只提供一个API调用，在一个请求中提供所有数据，而不进行分页。请注意，如果您有一个大型数据集，您将需要一些可以执行输出流而不临时将其加载到内存中的东西。

对于我的例子，我隐式地指定了一些API调用来允许获取全部信息(主要是引用表数据)。您还可以保护这些api，使其不会损害您的系统。

RESTFul api中的另一个分页选项是使用这里介绍的Link头。例如，Github使用它如下:

Link: <https://api.github.com/user/repos?page=3&per_page=100>; rel="next",
  <https://api.github.com/user/repos?page=50&per_page=100>; rel="last"

rel的可能值是:first, last, next, previous。但是通过使用Link头，可能无法指定total_count(元素的总数)。

我认为目前你的api的反应应该是这样的。页面上的前100条记录按照您所维护的对象的总体顺序排列。您的解释告诉我们，您正在使用某种排序id来定义分页对象的顺序。

现在，如果您希望第2页始终从101开始，到200结束，那么您必须将该页上的条目数量作为变量，因为它们可能会被删除。

你应该做如下的伪代码:

page_max = 100
def get_page_results(page_no) :

    start = (page_no - 1) * page_max + 1
    end = page_no * page_max

    return fetch_results_by_id_between(start, end)

选项A:带时间戳的键集分页

为了避免您提到的偏移量分页的缺点，您可以使用基于键集的分页。通常，实体有一个时间戳，说明它们的创建或修改时间。此时间戳可用于分页:只需将最后一个元素的时间戳作为下一个请求的查询参数传递。服务器反过来使用时间戳作为筛选条件(例如WHERE modificationDate >= receivedTimestampParameter)

{
    "elements": [
        {"data": "data", "modificationDate": 1512757070}
        {"data": "data", "modificationDate": 1512757071}
        {"data": "data", "modificationDate": 1512757072}
    ],
    "pagination": {
        "lastModificationDate": 1512757072,
        "nextPage": "https://domain.de/api/elements?modifiedSince=1512757072"
    }
}

这样，你就不会漏掉任何元素。这种方法对于许多用例来说应该足够好了。但是，请记住以下几点:

当一个页面的所有元素都具有相同的时间戳时，您可能会陷入无休止的循环。 当具有相同时间戳的元素重叠在两个页面时，可以将多个元素多次交付给客户端。

您可以通过增加页面大小和使用精确到毫秒的时间戳来减少这些缺点。

选项B:带有延续令牌的扩展键集分页

要处理上面提到的常规键集分页的缺点，可以向时间戳添加偏移量，并使用所谓的“延续令牌”或“游标”。偏移量是该元素相对于具有相同时间戳的第一个元素的位置。通常，令牌具有类似Timestamp_Offset的格式。它在响应中传递给客户端，并可以提交回服务器以检索下一页。

{
    "elements": [
        {"data": "data", "modificationDate": 1512757070}
        {"data": "data", "modificationDate": 1512757072}
        {"data": "data", "modificationDate": 1512757072}
    ],
    "pagination": {
        "continuationToken": "1512757072_2",
        "nextPage": "https://domain.de/api/elements?continuationToken=1512757072_2"
    }
}

令牌“1512757072_2”指向页面的最后一个元素，并表示“客户端已经获得了时间戳为1512757072的第二个元素”。这样，服务器就知道该往哪里继续。

请注意，您必须处理元素在两个请求之间发生更改的情况。这通常是通过向令牌添加校验和来实现的。这个校验和是对具有此时间戳的所有元素的id进行计算的。因此，我们最终得到了这样的令牌格式:Timestamp_Offset_Checksum。

有关此方法的更多信息，请参阅博客文章“使用延续令牌的Web API分页”。这种方法的一个缺点是实现起来很棘手，因为有许多需要考虑的极端情况。这就是为什么像continuation-token这样的库可以很方便(如果您使用Java/ JVM语言)。免责声明:我是这篇文章的作者和图书馆的合著者。

根据您的服务器端逻辑，可能有两种方法。

方法1:当服务器不够智能，无法处理对象状态时。

您可以将所有缓存记录的唯一id发送到服务器，例如["id1"，"id2"，"id3"，"id4"，"id5"，"id6"，"id7"，"id8"，"id9"，"id10"]和一个布尔参数，以知道您是在请求新记录(拉取以刷新)还是旧记录(加载更多)。

你的服务器应该负责返回新记录(加载更多的记录或通过拉取刷新的新记录)以及从["id1"，"id2"，"id3"，"id4"，"id5"，"id6"，"id7"，"id8"，"id9"，"id10"]中删除的记录的id。

例子:- 如果你请求加载更多，那么你的请求应该看起来像这样:-

{
        "isRefresh" : false,
        "cached" : ["id1","id2","id3","id4","id5","id6","id7","id8","id9","id10"]
}

现在假设你正在请求旧记录(加载更多)，假设“id2”记录被某人更新，“id5”和“id8”记录从服务器上删除，那么你的服务器响应应该是这样的

{
        "records" : [
{"id" :"id2","more_key":"updated_value"},
{"id" :"id11","more_key":"more_value"},
{"id" :"id12","more_key":"more_value"},
{"id" :"id13","more_key":"more_value"},
{"id" :"id14","more_key":"more_value"},
{"id" :"id15","more_key":"more_value"},
{"id" :"id16","more_key":"more_value"},
{"id" :"id17","more_key":"more_value"},
{"id" :"id18","more_key":"more_value"},
{"id" :"id19","more_key":"more_value"},
{"id" :"id20","more_key":"more_value"}],
        "deleted" : ["id5","id8"]
}

但在这种情况下，如果你有很多本地缓存记录，假设500，那么你的请求字符串将太长，像这样:-

{
        "isRefresh" : false,
        "cached" : ["id1","id2","id3","id4","id5","id6","id7","id8","id9","id10",………,"id500"]//Too long request
}

方法2:当服务器足够智能，可以根据日期处理对象状态时。

您可以发送第一个记录和最后一个记录的id以及前一个请求的纪元时间。这样，即使您有大量的缓存记录，您的请求也总是很小

例子:- 如果你请求加载更多，那么你的请求应该看起来像这样:-

{
        "isRefresh" : false,
        "firstId" : "id1",
        "lastId" : "id10",
        "last_request_time" : 1421748005
}

您的服务器负责返回last_request_time之后删除的记录的id，以及返回last_request_time之后在“id1”和“id10”之间更新的记录。

{
        "records" : [
{"id" :"id2","more_key":"updated_value"},
{"id" :"id11","more_key":"more_value"},
{"id" :"id12","more_key":"more_value"},
{"id" :"id13","more_key":"more_value"},
{"id" :"id14","more_key":"more_value"},
{"id" :"id15","more_key":"more_value"},
{"id" :"id16","more_key":"more_value"},
{"id" :"id17","more_key":"more_value"},
{"id" :"id18","more_key":"more_value"},
{"id" :"id19","more_key":"more_value"},
{"id" :"id20","more_key":"more_value"}],
        "deleted" : ["id5","id8"]
}

拉到刷新:-

加载更多