我有一个与Rest WebService通信的应用程序。我们希望实现一种策略，其中App将首先询问第一个X数量的项目，并且一旦它们全部使用它们，将要求下一个X.我的问题是关于在该实现中实现的最佳实践/模型/算法服务器来解决这个规范。
我们的方法A.
问题：如果我们在服务器上插入新数据怎么办？如果我们从服务器删除数据怎么办？如果在第一个请求发出时服务器有100个项目，它会将前10个项目发送到应用程序。但是，如果在第二次请求时服务器有300项，我们保持相同的逻辑（总数的10％），服务器将从30到60返回应用程序项目。不仅我们不会发送20项如果我们从服务器上删除了一些项目，我们将来可能会发送重复的项目。
我们的做法B.
问题：这就是我喜欢称之为懒惰的选择。因为它很容易保存我们发送给每个客户端的内容，然后只是将我们已发送的请求排除在未来的请求中，但就性能而言，这可能是一个大问题（想象一下，如果我们有10000个项目和20000个客户端。）
现在，是否有一种模式或最着名的做法来处理这样的问题？
我会考虑以下想法：
a）服务器在客户端第一次调用它时知道它总共有Z项（比如说100）。这是通过将客户端ID作为密钥保存在哈希表中的服务器端时间戳来处理的。
b）每次应用程序要求新项目时，它将返回一组N（比如10个）项目作为集合/数组/其他 - 加上一个数字通知客户尚未返回多少项目。
示例：（100项，每次10项）
最后，当服务器返回最后一项时，所以：
只要您跟踪在服务器上创建给定项目的时间（这可能是您出于其他原因已经完成的事情），您始终可以知道客户端是否首先调用包含在结果集中的给定项目。如果这对您有意义，同样适用于删除项目。
诀窍是跟踪您开始提供第一个请求的时间点，从那时起，您可以通过将时间戳与创建/删除时间戳对应来轻松查看是否已更改该集。您当然可以决定现在确实要通知客户创建新项目（因此它将在特定时间点获得与服务器状态一致的结果）。通过使响应数据集更复杂，您还可以提醒客户端，如果在您的情况下这是有意义的，那么它已经删除了“它旁边”的一个或多个对象。
警告：
虽然这应该为所述问题提供可行的解决方案，但请记住，实际实施必须考虑到由于订购而产生的问题。您必须根据您的情况决定是否必须进行管理：如果确实存在问题，则返回组结构（以及客户端解释）将变得更加复杂。
问题如下：在大多数情况下，结果集（尽管是“分页”）将具有一些固有的顺序：它可以是“按价格，按升序”或其他任何内容，具体取决于上下文。如果确实如此，那么现在有一个全新的问题要处理：
除非它确实是一个严格的要求，否则我会选择API根据第一次调用的时间戳返回一致的快照。
一个简单的策略：
步骤1检索要更新的项目列表
步骤2将该列表传输给客户端
步骤3将请求拆分为块（每页1000个条目）并逐页查询
步骤4在客户端上的条目上设置时间戳，例如justupdated = now()
步骤5检索要更新的项目列表，并减去刚刚更新的所有条目
步骤6直到有空集，重复步骤3
步骤7当delta为0时，您的更新已完成。
或者：
步骤1评估客户端上的所有过期条目（早于x）
步骤2查询来自客户端的所有过期条目的逐页更新，并设置更新时间戳
第3步询问服务器更新
步骤4查询页面并在客户端设置更新时间戳
步骤5询问服务器是否有更新
步骤6使用已更新的条目计算增量。直到delta = 0页面检索数据并设置时间戳。并重复步骤5
如果您保存了包含客户端上收到的所有项目的散列值的列表，并且每次都通过请求将其发送到服务器，该怎么办？