在追求通过REST API获取有关我最近修改的OneNote页面的最新信息时，我进行了一个简短的实验，创建了一个新的Outlook ID。使用Windows和Mac创建OneNote笔记本，部分和页面；并使用Graph Explorer运行OneNote API查询。我发现使用GET .../pages的页面信息请求无效，很可能是API信息未实时更新的结果。下面提供了更多详细信息；对于通过Microsoft Graph使用OneNote REST API从特定部分获取页面信息的任何其他见解或替代方法，我将不胜感激。
今天早些时候，我在Macbook Pro上使用Google Chrome创建了一个新的@ outlook.com帐户。然后，使用Mac版OneNote，我创建了一个新的笔记本，部分和页面。其所有方面均与OneNote Online实时同步。 但是，尽管状态为200，Microsoft Graph Explorer中的 GET https://graph.microsoft.com/v1.0/me/onenote/pages 调用仍未呈现任何页面信息。随后，我在附近的Windows计算机上登录了这个新的Outlook帐户，并能够立即同步OneNote for Windows中的所有内容。我在Windows机器上创建了一个新的笔记本，部分和页面，然后也在该机器上使用了Graph Explorer。 尽管状态为200，同一呼叫仍未呈现任何页面信息。从特定部分调用页面时也观察到这种情况。两台计算机之间的同步几乎是即时的。
我继续使用GET https://graph.microsoft.com/v1.0/me/onenote/sections和GET https://graph.microsoft.com/v1.0/me/onenote/notebooks。 这些调用分别提供了有关笔记本和分区的最新信息。另外，我通过Windows机器上的Graph Explorer将POST https://graph.microsoft.com/v1.0/me/onenote/sections/{section-id}/pages用于post a sample page（请参见“构造消息正文”下的代码）以访问我的部分之一。此页面立即在两台计算机上呈现。在Windows计算机上使用GET .../pages 仅返回此发布页面的信息。尽管状态为200，在Mac上通过Graph Explorer在Mac上进行的同一调用仍未呈现任何信息。
我以前发布了一个有关why there seemed to be a 3-day lag about page information from the OneNote API的问题。与此行为一致，似乎页面信息的更新（以天为单位）比笔记本或分区信息（以秒为单位）慢得多。此外，通过我自己的程序调用API时，也会看到相同的滞后行为。
在实时更新部分和笔记本信息时，通过GET .../pages调用的页面信息似乎无法正常工作。
此问题似乎与操作系统，单个帐户或打电话的应用程序无关，因为同时使用了Windows和Mac，结果与现有帐户和为此实验创建的新帐户之间的结果相当，使用Graph Explorer或通过R进行API调用时，结果可比。
此问题似乎仅限于获取页面信息或为API创建页面信息的功能或过程，因为官方OneNote程序之间的同步似乎是完整的。