【FAQ】運動健康服務REST API介面使用過程中常見問題和解決方法總結

華為運動健康服務（HUAWEI Health Kit）為三方生態應用提供了REST API介面，通過其介面可訪問資料庫，為使用者提供運動健康類資料服務。在實際的整合過程中，開發者們可能會遇到各種問題，這裡我們將典型問題進行分享和總結，希望為其他遇到類似問題的開發者提供參考。

1. 註冊訂閱通知能力後，連通性檢查失敗

在註冊成為訂閱者後，測試連通性檢查回撥通知地址時，提示“連通性檢查失敗，連通性檢查響應非204”。

原因分析：

在回撥通知地址可以訪問的情況下，需要開發者確認訂閱的回撥通知地址的HTTP狀態碼是否為204，否則將返回404表示回撥地址連通性檢驗失敗。

參考訂閱資料文件

解決方案：

檢查連結是否可用，且返回的狀態碼是否為204。

2. 取樣資料統計介面返回的步數總和與獲取步數明細資料後自己計算的總和不一致

用取樣資料統計查詢介面獲取步數總和

統計查詢介面：https://health-api.cloud.huaw...

請求引數：

{
    "polymerizeWith": [
        {
": 1651809600000,
    "startTime": 1651766400000,
    "groupByTime": {
        "groupPeriod": {
            "timeZone": "+0800",
            "unit": "day",
            "value": 1
        }
    }
}

最終返回的步數結果為7118

用取樣資料明細查詢介面獲取步數明細，並計算總和

明細查詢介面：https://health-api.cloud.huaw...

請求引數：

{
    "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."。