MS Graph API非分页结果分页处理问题及替代端点咨询

问题背景 #

之前使用Beta版端点获取特定应用的设备安装状态：

https://graph.microsoft.com/beta/deviceAppManagement/mobileApps/$ApplicationID/devicestatuses

该端点已不可用，改用Intune门户同款报告的端点：

https://graph.microsoft.com/beta/deviceManagement/reports/getDeviceInstallStatusReport

使用top/skip参数遍历记录时，结果不稳定，有时能获取全部数据，有时中途失败。已尝试添加500ms延迟、调整top值至999（实际被限制为50条），均未解决问题。

问题解答 #

1. 不稳定情况的原因 #

两种因素都可能导致：

• 限流触发：Graph API对Beta版端点有速率限制，500ms固定延迟可能不足以避开阈值，当设备数量多、请求次数频繁时，容易触发429（请求过多）错误，直接导致请求失败。
• 代码缺陷：当前脚本没有错误捕获与重试机制，一旦某次请求因网络波动、临时服务故障或限流失败，会直接终止运行，仅返回部分结果；此外循环条件($Skip - 50) -le $TotalRowCount存在逻辑漏洞——若某次返回记录数少于50（比如最后一页），会导致提前终止或无效请求。

2. top/skip分页是否为官方推荐，及更优方法 #

• 官方推荐性：对于getDeviceInstallStatusReport这类报告类端点，官方文档明确要求通过请求体中的top和skip参数实现遍历，这是当前唯一的官方支持方式。
• 更优优化方案：
  • 添加错误重试与限流处理：捕获Invoke-RestMethod的异常，检测到429响应时，读取响应头的Retry-After值设置延迟时间，而非固定500ms；对5xx类临时服务错误也进行重试。
  • 动态终止循环：每次请求后检查返回的value数组长度，若长度小于top值，说明已到最后一页，直接终止循环，避免无效请求。
  • 遵循实际top限制：该端点实际允许的top最大值为50（即使文档标注999），需以实际返回结果为准，不要强行设置超限值。

3. 支持分页的替代端点 #

有两个更可靠的支持OData分页的端点可获取应用安装状态：

• 端点1：https://graph.microsoft.com/beta/deviceAppManagement/mobileApps/{mobileAppId}/deviceStatuses
  若你之前认为该端点不可用，需先确认是否为权限缺失问题（需DeviceManagementApps.Read.All或DeviceManagementApps.ReadWrite.All权限），目前该端点仍在Beta版中提供服务，支持$skip、$top、$filter等OData参数，可直接分页获取数据。
• 端点2：https://graph.microsoft.com/beta/deviceManagement/mobileAppInstallStatuses
  支持通过@odata.nextLink自动实现分页，可通过$filter=mobileAppId eq '{ApplicationID}'筛选特定应用的安装状态，返回数据包含设备名称、用户信息、安装状态等所需字段，完全覆盖需求。

内容的提问来源于stack exchange，提问作者Eds