【FAQ】运动健康服务REST API接口使用过程中常见问题和解决方法总结

华为运动健康服务（HUAWEI Health Kit）为三方生态应用提供了REST API接口，通过其接口可访问数据库，为用户提供运动健康类数据服务。在实际的集成过程中，开发者们可能会遇到各种问题，这里我们将典型问题进行分享和总结，希望为其他遇到类似问题的开发者提供参考。

1. 注册订阅通知能力后，连通性检查失败

在注册成为订阅者后，测试连通性检查回调通知地址时，提示“连通性检查失败，连通性检查响应非204”。

原因分析：

在回调通知地址可以访问的情况下，需要开发者确认订阅的回调通知地址的HTTP状态码是否为204，否则将返回404表示回调地址连通性检验失败。

参考订阅数据文档

解决方案：

检查链接是否可用，且返回的状态码是否为204。

2. 采样数据统计接口返回的步数总和与获取步数明细数据后自己计算的总和不一致

用采样数据统计查询接口获取步数总和

统计查询接口：https://health-api.cloud.huawei.com/healthkit/v1/sampleSet:polymerize

请求参数：

{
    "polymerizeWith": [
        {
            "dataTypeName": "com.huawei.continuous.steps.delta"
        }
    ],
    "endTime": 1651809600000,
    "startTime": 1651766400000,
    "groupByTime": {
        "groupPeriod": {
            "timeZone": "+0800",
            "unit": "day",
            "value": 1
        }
    }
}

最终返回的步数结果为7118

用采样数据明细查询接口获取步数明细，并计算总和

明细查询接口：https://health-api.cloud.huawei.com/healthkit/v1/sampleSet:polymerize

请求参数：

{
    "polymerizeWith": [
        {
            "dataTypeName": "com.huawei.continuous.steps.delta"
        }
    ],
    "endTime": 1651809600000,
    "startTime": 1651766400000
}

根据返回的结果计算的步数总和为6280

通过数据可以看出，在时间段相同的前提下，采样数据统计接口返回的步数总和与根据步数明细计算的总和是不一致的。

原因分析：

是明细数据和统计数据不同的机制导致的。明细数据和统计数据是分开上报的，由于各种原因，明细数据可能会有丢失或延迟，导致两种数据不能完全匹配。
其次，在统计一天的数据时，聚合条件为以下参数时（见下图），返回的是上报的统计数据，而不是通过明细数据计算的数据。

解决方案：

采样数据统计查询时，按时间聚合，传入groupByTime参数，groupByTime中设置duration参数。

请求参数：

{
    "polymerizeWith": [
        {
            "dataTypeName": "com.huawei.continuous.steps.delta"
        }
    ],
    "endTime": 1651809600000,
    "startTime": 1651766400000,
    "groupByTime": {
        "duration": 86400000
    }
}

最终返回的结果是6280，与根据步数明细计算的总和一致。

3. 错误码403，错误信息“Insufficient Permission: Request had insufficient authentication scopes.”

原因分析：

403为拒绝请求，主要是scopes权限不足，导致拒绝请求。

解决方案：

（1）检查联盟卡片中是否申请了相关权限。

（2）检查认证鉴权时是否传入了申请的权限，且是否在授权页面进行了同意授权。

认证鉴权时是否传入了申请的权限

授权界面是否勾选了权限

4. 错误码400，错误信息“Insufficient Permission: Request had insufficient authentication scopes.”

案例：查询步数的采样数据明细

参数说明：

Access Token：根据首次认证鉴权的code码生成。

首次认证鉴权的时间（第一次生成code码的时间）：2022年5月7日上午8点左右。

采集数据的起始时间：

开始时间：2022-05-06 00:00:00（1651766400000）

结束时间：2022-05-06 12:00:00（1651809600000）

具体请求，见下图：

响应结果：

原因分析：

查询数据时，出于对用户数据的保护，只允许开发者查询在用户授权之后的数据。如果需要查询用户授权前的数据，开发者需要获取到“读取历史数据”权限的授权，如果用户未授予此权限，开发者在查询数据时设置的起始时间若早于用户授权时间，则起始时间将自动修正为用户首次授权的时间，这将导致查询错误（code：400，message: “Invalid startTime or endTime.”）或仅能查询到用户授权时间后的数据，与设置的起始时间不一致。
拿问题中的例子来说，由于用户未授予“读取历史数据”的权限，在开始时间为5月6日，首次授权时间为5月7日的情况下，开始时间会自动修正为首次授权时间，也就是5月7日，这就导致修正后的开始时间晚于了结束时间，因此才会返回了错误码400，错误信息"Invalid startTime or endTime."。