我的目标是保持一组用户发送的电子邮件的“实时”（或尽可能接近）信息。
我理想的解决方案是定期向API中的所有用户查询消息。此功能尚未实现（尚未？）。
我的第二选择是为组中的每个成员创建订阅（https://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/subscription_post_subscriptions），然后在我意识到事件后请求消息信息。问题是，在实践中，我只允许创建20-30个同时订阅（Issues to use Webhook for Microsoft Graph API），这可能还不够。
所以我坚持在循环中轮询所有用户。这种方法的主要问题是我找不到任何信息有多少请求“太多”，即我受到限制。我希望最大化请求数，以最大限度地缩短完成一个周期所需的时间。
想到的解决方案是开发一种自适应程序，该程序可以缓慢减少请求之间的时间直到受到限制，然后突然增加一些时间直到找到并保持良好的平衡。这似乎很多工作。现在我正在假设1 /秒是我可以安全去的最高点（每次往返平均0.5秒，然后再冷却0.5秒）。
一般来说，处理未知限制限制的最佳方法是什么，特别是Microsoft Graph？
编辑：
虽然我认为接受的答案是一个很好的回答，但它可能不适合所有情况。例如，如果您不想使用365 API，并且不介意使用beta功能，也许您可以查看this（delta令牌），它似乎是为与数据实时同步而设计的。
接受答案的唯一潜在缺点是你仍然需要为你想跟踪的每个用户订阅（我认为...），并且这些有限制。非常好奇其他人如何解决这个问题。