0

所以我从graph API得到的skip token是一个数字,根据我的理解(我可能错了),它表示需要跳过多少封电子邮件。

在我们的应用程序中,我们将该跳过令牌存储在我们的 db/memory 中,以便我们可以获取下一页电子邮件。因此,如果说用户当前的跳过令牌是 100,并且在我们使用跳过令牌 100 向服务器发送请求之前,该用户删除了 10 封电子邮件,那么如果仍然使用那 100 个跳过令牌会发生什么?

由于我不确定如何处理这种用户删除电子邮件的情况,我们的应用程序的工作方式是:我们总是对跳过令牌(如 -10)做一个减号,并检查我们是否可以找到任何电子邮件或时间戳重叠在当前响应和之前的响应之间,如果没有重叠,我们对跳过标记再做一次减法。这有点像倒退。我们停止做减法,直到找到重叠。

是否有意义?到目前为止,我注意到一些跳过令牌的响应将 nextLink 设为 null,而用户的收件箱中仍有新电子邮件。此外,我们错过了大约半年的几封电子邮件(这意味着电子邮件在用户的收件箱中,但我们的应用程序没有获取到)。

4

1 回答 1

2

Delta Query (Track Changes) A​​PI 可能更适合您的需求。它有效地允许您在某人的收件箱的更改日志中保留一个“书签”。

例如,不是保留跳过令牌,而是保留从调用中返回的 deltaLink /messages/delta。当您再次使用 deltaLink 调用 API 时,您将获得自上次调用 API + 新的 deltaLink 以来的一组更改。这使您可以与正在监视的收件箱中的更改保持“同步”。

API 参考文档在这里: https ://docs.microsoft.com/en-us/graph/delta-query-overview

于 2019-03-09T01:22:29.480 回答