OneNote 节流（图表）API
Throttling of OneNote (Graph) API
我们为我们的一个客户开发了一个导入解决方案。它将许多 OneNote 笔记本中包含的数据解析和转换为所需的专有数据结构，供客户端在另一个信息系统中存储和使用。
许多笔记本中都有大量数据，需要执行大量图形 API 查询才能检索所有数据。
本质上，我们构建了一个批量导入（本质上是批处理）解决方案，它遍历客户帐户下的所有 OneNote 笔记本，解析每个分区和页面数据，以及下载和存储所有页面内容- 包括 linked 文档和图像。 linked 文档和图像需要最多的 Graph API 查询。
执行这些导入时，会出现图形 API 节流问题。一段时间后，即使我们以相对较低的速率发送查询，我们也开始收到 429 错误。
关于数据量，客户笔记本的平均部分大小为 50-70 页。每个页面平均包含 link 到大约 5 个文档供下载。因此，它需要多达 70+350 个请求才能检索单个笔记本部分的所有页面内容和文件。我们的客户在笔记本中有很多这样的部分。反过来，还有很多笔记本。
我们需要为客户导入的多个笔记本中总共有大约 150 个这样的部分。考虑到上面的统计数据，这意味着我们的导入需要总共进行 60000-65000 个图 API 查询，估计。
为了不淹没 Graph API 服务并保持在限制范围内，我们进行了大量试验并逐渐将我们的请求率降低到每 4 秒仅 1 个查询。也就是说，每小时最多发出 900 个 Graph API 请求。
这已经使每个部分的导入速度明显变慢 - 但它是可以忍受的，即使这意味着我们的完整导入需要连续 72 小时才能完成。
然而 - 即使我们的节流逻辑以这种速度实施并证明有效，在大约 1 小时 10 分钟后，大约 1100 个后续查询，我们仍然从图表 API 中收到 429 "too many requests" 错误。因此，我们无法继续导入所有剩余的、未完成的笔记本部分。这使我们能够连续导入几个部分，然后等待一些随机的时间，然后我们才能手动尝试再次继续导入。
所以这是我们寻求帮助的问题 - 特别是来自 Microsoft 代表的帮助。 Microsoft 能否为我们提供一种方法，使我们能够以相当快的查询速率执行这些 60...65K 页面+文档的导入，而不会受到限制，这样我们就可以在连续的批处理过程中完成工作，为我们的客户？例如，作为一个单独的访问点（专用服务端点），也许是时间受限的，例如为我们在特定时期内的使用而配置——这样我们就可以在那个时期内执行所有必要的导入？
有关其他信息 - 我们目前使用以下图表加载数据 API URL-s（实际不同值的占位符在大括号之间用大写字母表示）：
笔记本部分下的页面：
https://graph.microsoft.com/v1.0/users/{USER}/onenote/sections/{SECTION_ID}/pages?...
页面内容：
https://graph.microsoft.com/v1.0/users/{USER}/onenote/pages/{PAGE_ID}/content
一个文件（文档或图像）例如link来自页面内容：
https://graph.microsoft.com/v1.0/{USER}/onenote/resources/{RESOURCE_ID}/$value
哪个调用最有可能导致限制？
在限制之前您可以检索什么 - 仅 pageids（总共 150 个调用）或 pageids+content（10000 个调用）？如果后者可以存储结果（例如 sql 数据库），这样您就不必再次调用这些结果。
如果您可以获得 pageids+content，那么您可以使用 preAuthenticated=true 访问资源（也许这不太可能受到限制）。我实际上不离线图像，因为我通常处理墨水或打印。
我发现 onenote API 对多个调用非常敏感，无需等待它们完成，我发现通过 curl 多技术进行的超过 12 个同时调用是有问题的。一旦你被扼杀了，如果你不立即退缩，你可能会被扼杀很长很长时间。如果我连续收到太多 429，我通常会让我的脚本保释（我将它设置为同时 10 个 429，它会保释 10 分钟）。
我们现在发布了解决方案并投入生产。事实证明，确实向页面添加 ?preAuthenticated=true 请求 returns 页面内容具有不同格式的资源链接（对于包含的文档、图像）。然后，看起来，查询这些资源链接不会影响 API 节流计数器 - 因为从那以后我们就没有出现 429 错误了。
我们甚至设法将调用速度从 4 秒降低到 2 秒，没有任何问题。所以我将codeeye的答案标记为已接受
我们为我们的一个客户开发了一个导入解决方案。它将许多 OneNote 笔记本中包含的数据解析和转换为所需的专有数据结构，供客户端在另一个信息系统中存储和使用。
许多笔记本中都有大量数据，需要执行大量图形 API 查询才能检索所有数据。
本质上，我们构建了一个批量导入（本质上是批处理）解决方案，它遍历客户帐户下的所有 OneNote 笔记本，解析每个分区和页面数据，以及下载和存储所有页面内容- 包括 linked 文档和图像。 linked 文档和图像需要最多的 Graph API 查询。
执行这些导入时，会出现图形 API 节流问题。一段时间后，即使我们以相对较低的速率发送查询，我们也开始收到 429 错误。
关于数据量，客户笔记本的平均部分大小为 50-70 页。每个页面平均包含 link 到大约 5 个文档供下载。因此，它需要多达 70+350 个请求才能检索单个笔记本部分的所有页面内容和文件。我们的客户在笔记本中有很多这样的部分。反过来，还有很多笔记本。
我们需要为客户导入的多个笔记本中总共有大约 150 个这样的部分。考虑到上面的统计数据，这意味着我们的导入需要总共进行 60000-65000 个图 API 查询，估计。
为了不淹没 Graph API 服务并保持在限制范围内，我们进行了大量试验并逐渐将我们的请求率降低到每 4 秒仅 1 个查询。也就是说，每小时最多发出 900 个 Graph API 请求。
这已经使每个部分的导入速度明显变慢 - 但它是可以忍受的，即使这意味着我们的完整导入需要连续 72 小时才能完成。
然而 - 即使我们的节流逻辑以这种速度实施并证明有效，在大约 1 小时 10 分钟后，大约 1100 个后续查询，我们仍然从图表 API 中收到 429 "too many requests" 错误。因此，我们无法继续导入所有剩余的、未完成的笔记本部分。这使我们能够连续导入几个部分，然后等待一些随机的时间，然后我们才能手动尝试再次继续导入。
所以这是我们寻求帮助的问题 - 特别是来自 Microsoft 代表的帮助。 Microsoft 能否为我们提供一种方法，使我们能够以相当快的查询速率执行这些 60...65K 页面+文档的导入，而不会受到限制，这样我们就可以在连续的批处理过程中完成工作，为我们的客户？例如，作为一个单独的访问点（专用服务端点），也许是时间受限的，例如为我们在特定时期内的使用而配置——这样我们就可以在那个时期内执行所有必要的导入？
有关其他信息 - 我们目前使用以下图表加载数据 API URL-s（实际不同值的占位符在大括号之间用大写字母表示）：
笔记本部分下的页面：
https://graph.microsoft.com/v1.0/users/{USER}/onenote/sections/{SECTION_ID}/pages?...
页面内容：
https://graph.microsoft.com/v1.0/users/{USER}/onenote/pages/{PAGE_ID}/content
一个文件（文档或图像）例如link来自页面内容：
https://graph.microsoft.com/v1.0/{USER}/onenote/resources/{RESOURCE_ID}/$value
哪个调用最有可能导致限制？
在限制之前您可以检索什么 - 仅 pageids（总共 150 个调用）或 pageids+content（10000 个调用）？如果后者可以存储结果（例如 sql 数据库），这样您就不必再次调用这些结果。
如果您可以获得 pageids+content，那么您可以使用 preAuthenticated=true 访问资源（也许这不太可能受到限制）。我实际上不离线图像，因为我通常处理墨水或打印。
我发现 onenote API 对多个调用非常敏感，无需等待它们完成，我发现通过 curl 多技术进行的超过 12 个同时调用是有问题的。一旦你被扼杀了，如果你不立即退缩，你可能会被扼杀很长很长时间。如果我连续收到太多 429，我通常会让我的脚本保释（我将它设置为同时 10 个 429，它会保释 10 分钟）。
我们现在发布了解决方案并投入生产。事实证明，确实向页面添加 ?preAuthenticated=true 请求 returns 页面内容具有不同格式的资源链接（对于包含的文档、图像）。然后，看起来，查询这些资源链接不会影响 API 节流计数器 - 因为从那以后我们就没有出现 429 错误了。
我们甚至设法将调用速度从 4 秒降低到 2 秒，没有任何问题。所以我将codeeye的答案标记为已接受