ملاحظة مهمة: سينتهي الدعم لواجهة برمجة التطبيقات القديمة Fitbit Web API في 30 سبتمبر 2026. بعد هذا التاريخ، ستظل واجهة برمجة التطبيقات تعمل، ولكن لن تعود Google تصلح الأخطاء أو تقدّم الدعم لواجهة برمجة التطبيقات. في 30 أكتوبر 2026، سيتم إيقاف واجهة برمجة التطبيقات Fitbit Web API ولن تعود تعمل أو تُزامِن البيانات من مستخدمي Fitbit وإليهم. لمواصلة الوصول إلى بيانات المستخدمين بعد هذا التاريخ، يُرجى الانتقال إلى Google Health API. للحصول على إرشادات بشأن عملية الانتقال، يُرجى الاطّلاع على دليل نقل البيانات من Fitbit Web API.

تستخدم Google تكنولوجيا الذكاء الاصطناعي لترجمة المحتوى إلى لغتك المفضّلة، وقد تتضمّن بعض الأخطاء.

نقاط النهاية

تقدّم هذه الصفحة نظرة عامة على اصطلاحات REST API، بالإضافة إلى فهرس للمهام الشائعة في Google Health API وأمثلة على كل منها.

اتّفاقيات REST API

تتّبع Google Health API معايير مقترحات تحسين واجهات برمجة التطبيقات من Google (AIP)، وتحديدًا AIP-127 (تحويل الترميز إلى HTTP وgRPC) وAIP-131 إلى AIP-135 (الطرق العادية). تحدّد هذه المعايير كيفية ربط البيانات من رسالة proto بطلب HTTP.

مَعلمات طلب البحث

يتم استخدام مَعلمات طلب البحث عندما تكون البيانات جزءًا من عنوان URL. يتم استخدام هذا الحقل بشكل أساسي لطلبات GET (استرداد مورد) أو طلبات LIST (الفلترة/التقسيم إلى صفحات)، ولكن يتم استخدامه أيضًا لعمليات DELETE.

موضع الإعلان: يتم إلحاقه بعنوان URL بعد ?.
البنية: أزواج المفتاح/القيمة مفصولة بـ &.
الربط: يتم ربط كل حقل في رسالة الطلب لا يشكّل جزءًا من نموذج مسار عنوان URL بمَعلمة طلب بحث.
الأفضل للاستخدام مع: الأنواع البسيطة (السلاسل والأعداد الصحيحة والقيم الثابتة) والحقول المتكرّرة

مثال على بنية الجملة:

GET https://health.googleapis.com/v4/users/me/dataTypes/data-type/dataPoints?page_size=10&filter=data_type.interval.start_time >= "2025-10-01T00:00:00Z"

نص الطلب

يتم استخدام نص الطلب عندما تعدّل البيانات حالة أحد الموارد أو عندما تكون كبيرة جدًا بحيث لا يمكن تضمينها في عنوان URL. يتضمّن النص عادةً تمثيلاً بتنسيق JSON للمورد نفسه. يُستخدم عادةً في عمليات POST وPATCH وPUT.

موضع الإعلان: داخل حمولة HTTP (غير مرئي في عنوان URL)
البنية: يتم تنسيقها كعنصر JSON.
عملية الربط: يتم تحديدها في التعليق التوضيحي google.api.http.
- body: "*" تعني أنّ الرسالة بأكملها هي النص.
- يشير body: "resource_name" إلى أنّ حقلًا معيّنًا فقط في البروتوكول هو النص الأساسي.
الأفضل للاستخدام مع: العناصر المعقّدة والرسائل المتداخلة والبيانات الحسّاسة

مثال على بنية الجملة:

POST https://health.googleapis.com/v4/users/me/dataTypes/data-type/dataPoints:rollUp
Content-Type: application/json

{
  "range": {
    "startTime": "2025-11-05T00:00:00Z",
    "endTime": "2025-11-13T00:00:00Z"
  },
  "windowSize": "3600s"
}

حالة الاستخدام المختلطة

في طريقة Update متوافقة مع AIP-134 أو عملية PATCH، يتم استخدام كليهما. يحتوي عنوان URL على اسم المرجع، ويحتوي النص على بيانات المرجع المعدَّلة، ويحدّد مَعلمة طلب البحث (عادةً update_mask) الحقول التي سيتم تغييرها.

PATCH https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id
Content-Type: application/json

{
  "endpointUri": "https://myapp.com/new-webhooks/health"
}

نظرة سريعة على الاختلافات الرئيسية

الميزة	معلمات طلب البحث	نص الطلب
إرشادات AIP	تُستخدَم في عمليات البحث والفلترة والقراءة.	يُستخدَم لعمليات الكتابة.
مستوى العرض	تظهر في سجلّ المتصفّح وسجلّات الخادم.	مخفي من عنوان URL
التعقيد	يقتصر على البُنى المسطّحة أو المتكرّرة.	يتيح استخدام عناصر JSON متداخلة بشكل كبير.
الترميز	يجب أن يكون عنوان URL مرمَّزًا (على سبيل المثال، تصبح المسافات `%20`).	ترميز JSON العادي

التواريخ

يتم عرض جميع التواريخ في Google Health API بالتنسيق YYYY-MM-DD. تتيح واجهة برمجة التطبيقات Nutrition API استخدام معيار ISO-8601 لقيم التاريخ مع استيفاء الشروط التالية:

سنة مؤلفة من 4 أرقام YYYY
قيم السنوات ضمن النطاق 0000-9999
عدم فرض قيود على تاريخ البدء ضمن معيار ISO-8601 أو أي فترة زمنية أخرى

العناوين

يتطلّب تنفيذ نقاط نهاية Google Health API استخدام العناوين المناسبة ورمز الدخول. يُنصح باستخدام العنوان التالي لكلّ من طلبات GET وPOST:

Authorization: Bearer access-token
Accept: application/json

فهرس مهام واجهة برمجة التطبيقات

يقدّم هذا القسم فهرسًا لمهام Google Health API الشائعة وأمثلة على كل منها.

الحصول على رقم تعريف مستخدم Fitbit أو Google

بعد موافقة المستخدم من خلال Google OAuth 2.0، لن يتضمّن رد الرمز المميّز معرّف مستخدم Fitbit أو Google. للحصول على رقم تعريف المستخدم، اتّصِل بنقطة النهاية getIdentity. getIdentity تعرض هذه السمة رقم تعريف المستخدم القديم في Fitbit ورقم تعريف المستخدم في Google.

ننصحك بأنّه فور موافقة مستخدم جديد من خلال OAuth، عليك طلب نقطة النهاية getIdentity وتخزين معرّفَي المستخدمَين. ويوفّر ذلك توافقًا مع الإصدارات القديمة والجديدة في عملية الدمج.

على سبيل المثال:

طلب

GET https://health.googleapis.com/v4/users/me/identity
Authorization: Bearer access-token
Accept: application/json

الردّ

{
  "name": "users/me/identity",
  "legacyUserId": "A1B2C3",
  "healthUserId": "111111256096816351"
}

الحصول على بيانات مفصّلة أو بيانات خلال اليوم تم جمعها على مدار يوم كامل

استخدِم نقطة النهاية list لنوع بيانات معيّن للحصول على بيانات مفصّلة أو بيانات خلال اليوم تم جمعها على مدار اليوم في فواصل زمنية متوافقة لنوع البيانات هذا.

على سبيل المثال:

طلب

GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints
Authorization: Bearer access-token
Accept: application/json

الردّ

{
  "dataPoints": [
    {
      "dataSource": {
        "recordingMethod": "PASSIVELY_MEASURED",
        "device": {
          "manufacturer": "",
          "displayName": "Charge 6"
        },
        "platform": "FITBIT"
      },
      "steps": {
        "interval": {
          "startTime": "2026-03-04T07:05:00Z",
          "startUtcOffset": "0s",
          "endTime": "2026-03-04T07:06:00Z",
          "endUtcOffset": "0s",
          "civilStartTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 5
            }
          },
          "civilEndTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 6
            }
          }
        },
        "count": "40"
      }
    },
...
  ],
  "nextPageToken": "Xm5h-6L0viZxIlRuWjx5bmvy98zj85uG34tuMn16mu2pntsnZI32iqhq"
}

الحصول على عرض متوافق لبيانات الفترات

لاسترداد بيانات الفترات بدون سجلّات متداخلة أو تعارضات بين أجهزة متعددة، استخدِم نقطة النهاية reconcile. تعمل نقطة النهاية reconcile على إزالة التكرار تلقائيًا من الفواصل الزمنية المتداخلة في جميع حِزم المزامنة وأجهزة التسجيل المتعددة، وتعرض بثًا موثوقًا ومتواصلاً مناسبًا لعرض المخططات الزمنية للنشاط واحتساب المدد.

للحصول على معلومات أساسية حول سبب إنتاج الأجهزة المرتبطة لفواصل زمنية متداخلة ومقارنة تشغيلية بين list وreconcile، راجِع دليل إدارة البيانات.

يقارن المثال التالي بين استجابة list (التي تعرض السجلات المتداخلة) واستجابة reconcile (التي تحلّ التعارض من خلال عرض السجل الموثوق) لمستخدم لديه جلستا تمرين متداخلتان:

قائمة غير منسَّقة

GET https://health.googleapis.com/v4/users/me/dataTypes/exercise/dataPoints
Authorization: Bearer access-token
Accept: application/json

{
  "dataPoints": [
    {
      "name": "users/111111256096816351/dataTypes/exercise/dataPoints/7797422996486764704",
      "exercise": {
        "interval": {
          "startTime": "2026-09-03T11:20:00Z",
          "endTime": "2026-09-03T11:50:00Z"
        },
        "exerciseType": "RUNNING"
      }
    },
    {
      "name": "users/111111256096816351/dataTypes/exercise/dataPoints/4389052750481144696",
      "exercise": {
        "interval": {
          "startTime": "2026-09-03T11:00:00Z",
          "endTime": "2026-09-03T11:30:00Z"
        },
        "exerciseType": "RUNNING"
      }
    }
  ]
}

تمت التسوية

GET https://health.googleapis.com/v4/users/me/dataTypes/exercise/dataPoints:reconcile
Authorization: Bearer access-token
Accept: application/json

{
  "dataPoints": [
    {
      "dataPointName": "users/111111256096816351/dataTypes/exercise/dataPoints/7797422996486764704",
      "exercise": {
        "interval": {
          "startTime": "2026-09-03T11:20:00Z",
          "endTime": "2026-09-03T11:50:00Z"
        },
        "exerciseType": "RUNNING"
      }
    }
  ]
}

تعمل عملية التسوية على حلّ الجلسات المتعارضة من خلال إزالة التكرار واختيار السجلّ الموثوق بدلاً من إنشاء اتحاد زمني اصطناعي (مثل 11:00:00Z إلى 11:50:00Z). وتعرض الاستجابة التي تمّت تسويتها نقطة البيانات الفائزة (7797422996486764704) مع الفاصل الزمني الأصلي المسجّل (11:20:00Z إلى 11:50:00Z)، ما يحافظ على سلامة بيانات القياس عن بُعد والمقاييس التي تمّت خلال تلك الجلسة.

تصفية البيانات

لاسترداد مجموعات فرعية محدّدة من سجلّات نقاط البيانات التي تتطابق مع معايير معيّنة، مثل فاصل زمني أو تاريخ أو وقت الملاحظة، استخدِم نقطة النهاية list أو reconcile مع المَعلمة filter.

للحصول على إرشادات تفصيلية وقواعد التنسيق وأخطاء التحقّق وأمثلة على طلبات البحث، يُرجى الاطّلاع على دليل فلترة البيانات.

الفلترة حسب مجموعة مصادر البيانات

لعزل البيانات أو تجميعها من أنواع معيّنة من المصادر (مثل الأجهزة القابلة للارتداء المادية مقابل الإدخالات اليدوية)، استخدِم المَعلمة dataSourceFamily.

للاطّلاع على إرشادات تفصيلية والفئات المتوافقة وأمثلة على الطلبات والردود بالنسبة إلى reconcile وrollUp وdailyRollUp، يُرجى الاطّلاع على الفلترة حسب فئة مصدر البيانات في دليل فلترة البيانات.

فلترة البيانات حسب وقت بدء مدني لفترة زمنية

استخدِم نقطة النهاية list مع المَعلمة filter لفلترة البيانات حسب الوقت المدني أو الفترة الزمنية.

ملاحظة مهمة: يختلف تنسيق معرّفات أنواع البيانات عندما يتضمّن نوع البيانات أكثر من كلمة واحدة. في نقطة نهاية، يجب أن يكون اسم نوع البيانات بتنسيق kebab-case، مثل body-fat. في مَعلمة فلتر، يجب أن يكون اسم نوع البيانات بتنسيق snake case، مثل body_fat.

على سبيل المثال:

طلب

GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints?filter=steps.interval.civil_start_time >= "2026-03-04T00:00:00"
Authorization: Bearer access-token
Accept: application/json

الردّ

{
  "dataPoints": [
    {
      "dataSource": {
        "recordingMethod": "PASSIVELY_MEASURED",
        "device": {
          "manufacturer": "",
          "displayName": "Charge 6"
        },
        "platform": "FITBIT"
      },
      "steps": {
        "interval": {
          "startTime": "2026-03-04T07:05:00Z",
          "startUtcOffset": "0s",
          "endTime": "2026-03-04T07:06:00Z",
          "endUtcOffset": "0s",
          "civilStartTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 5
            }
          },
          "civilEndTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 6
            }
          }
        },
        "count": "40"
      }
...
  ],
  "nextPageToken": "Xm5h-6L0viZxIlRuQjp5bml1bZ4ve2dhNmZvMnt4Yn7qIGQhbHN3YQ"
}

فلترة البيانات حسب الوقت الفعلي لملاحظة نموذجية

استخدِم نقطة النهاية list مع المَعلمة filter لفلترة البيانات حسب الوقت الفعلي لملاحظة العيّنة.

على سبيل المثال:

طلب

GET https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints?filter=body_fat.sample_time.physical_time >= "2026-03-01T00:00:00Z"
Authorization: Bearer access-token
Accept: application/json

الردّ

{
  "dataPoints": [
    {
      "name": "users/123456789/dataTypes/body-fat/dataPoints/1234567890",
      "dataSource": {
        "recordingMethod": "UNKNOWN",
        "application": {
          "packageName": "",
          "webClientId": "",
          "googleWebClientId": "google-web-client-id"
        },
        "platform": "GOOGLE_WEB_API"
      },
      "bodyFat": {
        "sampleTime": {
          "physicalTime": "2026-03-10T10:00:00Z",
          "utcOffset": "0s",
          "civilTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 10
            },
            "time": {
              "hours": 10
            }
          }
        },
        "percentage": 20
      }
    }
  "nextPageToken": ""
}

الفلترة والتجميع حسب مجموعة مصادر البيانات

مجموعة مصادر البيانات هي مجموعة منطقية من مصادر البيانات (مثل الساعات الذكية أو تطبيقات الأجهزة الجوّالة أو الإدخالات اليدوية). تتيح لك هذه الميزة عزل البيانات أو تجميعها من أنواع معيّنة من المصادر (على سبيل المثال، الأجهزة القابلة للارتداء مقابل الإدخالات اليدوية).

تتوافق نقاط النهاية reconcile وrollUp وdailyRollUp مع المَعلمة dataSourceFamily. تعتمد آلية تمرير البيانات على نقطة النهاية:

نقطة النهاية (طريقة HTTP)	الآلية
‫`reconcile` (GET)	مرِّر `dataSourceFamily` كمعلَمة طلب بحث في عنوان URL.
‫`rollUp` (POST)	مرِّر `dataSourceFamily` كحقل في نص طلب JSON.
‫`dailyRollUp` (POST)	مرِّر `dataSourceFamily` كحقل في نص طلب JSON.

مجموعات مصادر البيانات المتوافقة

يوضّح الجدول التالي قيم dataSourceFamily المتوافقة:

Option	الوصف
`users/me/dataSourceFamilies/all-sources`	القيمة التلقائية: تعرض نقاط البيانات التي تمّت مطابقتها في جميع مصادر بيانات الطرف الأوّل (1P) والطرف الثالث (3P) المسجّلة. سيتم عرض بيانات التطبيقات الخارجية مع هذا الخيار (مثل خطوات الساعة الذكية + خطوات التطبيقات الخارجية + خطوات الهاتف الجوّال + الخطوات التي تم إدخالها يدويًا).
`users/me/dataSourceFamilies/google-wearables`	تشمل البيانات المسجّلة بواسطة أجهزة التتبُّع من Google وFitbit (مثل أجهزة التتبُّع القابلة للارتداء من Fitbit وPixel Watch). لا يشمل ذلك البيانات التي يتم تسجيلها يدويًا والبيانات المقدَّرة من الهاتف. استخدِم هذا الخيار عندما يتطلّب التكامل بيانات قياس عن بُعد من أجهزة الاستشعار يتم تسجيلها مباشرةً بواسطة أجهزة قابلة للارتداء.
`users/me/dataSourceFamilies/google-sources`	يتضمّن مصادر Google وFitbit التابعة للطرف الأول. ويشمل ذلك سجلات أجهزة التتبُّع البدني والبيانات من Health Connect وأي إدخالات يدوية تم تسجيلها من خلال تطبيقات تابعة لجهات أولى (مثل تطبيق Fitbit أو Google Fit).

للحصول على مصدر بيانات موحّد من مجموعة مصادر بيانات معيّنة، استخدِم نقطة النهاية reconcile مع مَعلمة طلب البحث dataSourceFamily.

على سبيل المثال، يجلب طلب استرداد بيانات باستخدام GET التالي بيانات النوم المسجّلة باستخدام جهاز تتبُّع في اليوم التالي لتاريخ 03-03-2026:

طلب

GET https://health.googleapis.com/v4/users/me/dataTypes/sleep/dataPoints:reconcile?dataSourceFamily=users/me/dataSourceFamilies/google-wearables&filter=sleep.interval.civil_end_time >= "2026-03-03"
Authorization: Bearer access-token
Accept: application/json

الردّ

{
  "dataPoints": [
    {
      "name": "users/2515055256096816351/dataTypes/sleep/dataPoints/2724123844716220216",
      "dataSource": {
        "recordingMethod": "DERIVED",
        "device": {
          "displayName": "Charge 6"
        },
        "platform": "FITBIT"
      },
      "sleep": {
        "interval": {
          "startTime": "2026-03-03T20:57:30Z",
          "startUtcOffset": "0s",
          "endTime": "2026-03-04T04:41:30Z",
          "endUtcOffset": "0s"
        },
        "type": "STAGES",
        "stages": [
          {
            "startTime": "2026-03-03T20:57:30Z",
            "startUtcOffset": "0s",
            "endTime": "2026-03-03T20:59:30Z",
            "endUtcOffset": "0s",
            "type": "AWAKE",
            "createTime": "2026-03-04T04:43:40.937183Z",
            "updateTime": "2026-03-04T04:43:40.937183Z"
          },
          {
            "startTime": "2026-03-04T04:07:30Z",
            "startUtcOffset": "0s",
            "endTime": "2026-03-04T04:41:30Z",
            "endUtcOffset": "0s",
            "type": "AWAKE",
            "createTime": "2026-03-04T04:43:40.937183Z",
            "updateTime": "2026-03-04T04:43:40.937183Z"
          }
        ],
        "metadata": {
          "stagesStatus": "SUCCEEDED",
          "processed": true,
          "main": true
        },
        "summary": {
          "minutesInSleepPeriod": "464",
          "minutesAfterWakeUp": "0",
          "minutesToFallAsleep": "0",
          "minutesAsleep": "407",
          "minutesAwake": "57",
          "stagesSummary": [
            {
              "type": "AWAKE",
              "minutes": "56",
              "count": "12"
            },
            {
              "type": "LIGHT",
              "minutes": "198",
              "count": "19"
            },
            {
              "type": "DEEP",
              "minutes": "114",
              "count": "10"
            },
            {
              "type": "REM",
              "minutes": "94",
              "count": "4"
            }
          ]
        },
        "createTime": "2026-03-04T04:43:40.337983Z",
        "updateTime": "2026-03-04T04:43:40.937183Z"
      }
    }
  ],
  "nextPageToken": ""
}

لتجميع نقاط البيانات على مدى فترة زمنية محدّدة ضمن مجموعة معيّنة من مصادر البيانات، يمكنك طلب نقطة النهاية rollUp وتمرير الحقل dataSourceFamily في نص طلب JSON.

يستعلم طلب POST التالي عن عدد خطوات المشي خلال اليوم على فترات زمنية كل ساعة (3600s)، ويتم تجميع البيانات حصريًا من الأجهزة القابلة للارتداء:

طلب

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:rollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "startTime": "2026-07-29T00:00:00Z",
    "endTime": "2026-07-29T23:59:59Z"
  },
  "windowSize": "3600s",
  "dataSourceFamily": "users/me/dataSourceFamilies/google-wearables"
}

الردّ

{
  "rollupDataPoints": [
    {
      "startTime": "2026-07-29T08:00:00Z",
      "endTime": "2026-07-29T09:00:00Z",
      "steps": {
        "countSum": "1200"
      }
    },
    {
      "startTime": "2026-07-29T09:00:00Z",
      "endTime": "2026-07-29T10:00:00Z",
      "steps": {
        "countSum": "3450"
      }
    }
  ]
}

لتجميع نقاط البيانات اليومية لعائلة مصدر معيّنة، استدعِ نقطة النهاية dailyRollUp وأدخِل الحقل dataSourceFamily في نص الطلب.

على سبيل المثال، يحسب الطلب التالي عمليات التجميع اليومية لخطوات المستخدم، بما في ذلك جميع مصادر Google وFitbit التابعة للطرف الأول (الأجهزة القابلة للارتداء والإدخالات اليدوية):

طلب

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:dailyRollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "start": {
      "date": {
        "year": 2026,
        "month": 7,
        "day": 28
      },
      "time": {
        "hours": 0,
        "minutes": 0,
        "seconds": 0,
        "nanos": 0
      }
    },
    "end": {
      "date": {
        "year": 2026,
        "month": 7,
        "day": 30
      },
      "time": {
        "hours": 0,
        "minutes": 0,
        "seconds": 0,
        "nanos": 0
      }
    }
  },
  "windowSizeDays": 1,
  "dataSourceFamily": "users/me/dataSourceFamilies/google-sources"
}

الردّ

{
  "rollupDataPoints": [
    {
      "civilStartTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 28
        },
        "time": {}
      },
      "civilEndTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 28
        },
        "time": {
          "hours": 23,
          "minutes": 59,
          "seconds": 59
        }
      },
      "steps": {
        "countSum": "8430"
      }
    },
    {
      "civilStartTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 29
        },
        "time": {}
      },
      "civilEndTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 29
        },
        "time": {
          "hours": 23,
          "minutes": 59,
          "seconds": 59
        }
      },
      "steps": {
        "countSum": "11245"
      }
    }
  ]
}

تجميع نقاط البيانات على مدار فترة زمنية

استخدِم نقطة النهاية rollUp لعرض إجمالي نقاط البيانات استنادًا إلى فترة زمنية بالثواني، وذلك على مدى النطاق datetime استنادًا إلى الوقت الفعلي للمستخدم (بالتوقيت العالمي المنسَّق).

عند استدعاء نقطة النهاية rollUp، قدِّم نص الطلب الذي يمثّل النطاق الزمني المطلوب وwindowSize. يجب استيفاء المتطلبات التالية لاستخدام windowSize:

الحد الأدنى لحجم النافذة: يجب أن تبلغ مدة windowSize ثانية واحدة على الأقل ("1s"). سيتم رفض المدد التي تقل عن ثانية واحدة أو تساوي صفرًا أو سالبة مع عرض الخطأ 400 Bad Request (INVALID_ROLLUP_WINDOW).
توافق دقة التخزين: لتجنُّب التوزيع غير المتساوي للبيانات المجمّعة على مستوى الأقسام الفرعية، اختَر windowSize يساوي أو يزيد عن دقة التخزين الأساسية لنوع البيانات (مثل "60s" لفواصل الخطوات التي تبلغ دقتها دقيقة واحدة). لمعرفة التفاصيل، يُرجى الاطّلاع على حجم نافذة التجميع ودقة مساحة التخزين الأساسية.

على سبيل المثال، لدمج عدد الخطوات في فواصل زمنية مدتها دقيقة واحدة (60s):

طلب

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:rollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "startTime": "2026-02-17T17:00:00Z",
    "endTime": "2026-02-17T17:59:59Z"
  },
  "windowSize": "60s"
}

الردّ

{
  "rollupDataPoints": [
    {
      "startTime": "2026-02-17T17:55:00Z",
      "endTime": "2026-02-17T17:56:00Z",
      "steps": {
        "countSum": "72"
      }
    },
    {
      "startTime": "2026-02-17T17:54:00Z",
      "endTime": "2026-02-17T17:55:00Z",
      "steps": {
        "countSum": "85"
      }
    },
...
  ]
}

تجميع البيانات على مدار يوم واحد أو عدة أيام

يجب استخدام dailyRollUp نقطة النهاية عندما تريد تجميع البيانات على مدار يوم واحد أو عدة أيام، ويُعرف ذلك باسم windowSize. قدِّم النطاق الزمني المدني المغلق المفتوح للفاصل الزمني المطلوب في نص الطلب. استنادًا إلى نوع البيانات، ستتلقّى إما المجموع أو المتوسط خلال الفترة الزمنية.

على سبيل المثال:

طلب

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:dailyRollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "start": {
      "date": {
        "year": 2026,
        "month": 2,
        "day": 26
      },
      "time": {
        "hours": 0,
        "minutes": 0,
        "seconds": 0,
        "nanos": 0
      }
    },
    "end": {
      "date": {
        "year": 2026,
        "month": 2,
        "day": 26
      },
      "time": {
        "hours": 23,
        "minutes": 59,
        "seconds": 59,
        "nanos": 0
      }
    }
  },
  "windowSizeDays": 1
}

الردّ

{
  "rollupDataPoints": [
    {
      "civilStartTime": {
        "date": {
          "year": 2026,
          "month": 2,
          "day": 26
        },
        "time": {}
      },
      "civilEndTime": {
        "date": {
          "year": 2026,
          "month": 2,
          "day": 26
        },
        "time": {
          "hours": 23,
          "minutes": 59,
          "seconds": 59
        }
      },
      "steps": {
        "countSum": "3822"
      }
    }
  ]
}

تصنيف البيانات إلى مجموعات عندما لا يكون النطاق مضاعفًا لحجم النافذة

إذا لم يكن النطاق المطلوب مضاعفًا دقيقًا لـ windowSize (أو windowSizeDays)، سيتم اقتطاع الحزمة الأخيرة زمنيًا عند نقطة النهاية العليا للنطاق وستغطي مدة أقصر من حجم النافذة. تقبل واجهة برمجة التطبيقات طلبك بدون تعديل، ولا تجري أي تقريب أو تغييرات في الوقت أو استيفاء للبيانات.

لتغطية النطاق المطلوب بالكامل، تستخدم واجهة برمجة التطبيقات عملية القسمة لأعلى عدد صحيح لاحتساب إجمالي عدد فترات التجميع:

Number of windows = ceiling(Range duration / Window size)

يبدأ كل قسم بالتسلسل من بداية نطاقك. إذا كانت إضافة نافذة أخرى بالحجم الكامل ستتجاوز وقت النهاية المطلوب، سيتم اقتطاع النافذة الأخيرة (تحديدها) عند وقت نهاية النطاق.

طريقة عمل التقسيم إلى مجموعات

عند طلب ملخّصات بنطاقات غير قابلة للقسمة، تطبّق واجهة برمجة التطبيقات القواعد التالية:

يبدأ التقسيم إلى مجموعات في بداية النطاق المطلوب (range.startTime أو range.start) ويتقدّم للأمام حسب حجم النافذة (windowSize أو windowSizeDays).
يتم تثبيت آخر مجموعة زمنية متسلسلة في نهاية النطاق المطلوب (range.endTime أو range.end)، ما يعني أنّها تغطي مدة أقصر من حجم الفترة الزمنية المطلوبة.
تحدّد الكائنان RollupDataPoint أو DailyRollupDataPoint المعروضان بشكل صريح الطابعَين الزمنيَّين الخاصَّين بالبدء والانتهاء، ويمكنك استخدامهما لفحص المدة الفعلية للحزمة المقتطعة.
بما أنّ واجهة برمجة التطبيقات تعرض بيانات التجميع بترتيب زمني عكسي (الأحدث أولاً)، يظهر آخر جزء زمني (وهو الجزء المقتطع) كالعنصر الأول (index 0) في القائمة المعروضة.

السيناريو: نطاق 12 دقيقة مع فترة زمنية مدتها 5 دقائق

لنفترض أنّ أحد العملاء يطلب تجميع البيانات على مدى 12 دقيقة مع فترة 5 دقائق windowSize:

range.startTime: 10:00:00
‫range.endTime: 10:12:00 (المدة الإجمالية: 12 دقيقة)
windowSize: 5 minutes

بما أنّ 12 دقيقة ليس مضاعفًا لـ 5 دقائق (12 = 5 * 2 + 2)، تقبل واجهة برمجة التطبيقات الطلب وتحسب عدد الفترات الزمنية على النحو التالي: ceiling(12 / 5) = 3.

ينتج عن ذلك ثلاث مجموعات زمنية متسلسلة على النحو التالي:

المجموعة 1: [10:00:00, 10:05:00) — المدة: 5 دقائق (النافذة الكاملة)
المجموعة 2: [10:05:00, 10:10:00) — المدة: 5 دقائق (النافذة الكاملة)
المجموعة 3 (مقتطعة): [10:10:00, 10:12:00) — المدة: دقيقتان (تم الاقتطاع عند range.endTime)

التأثير في القيم المجمّعة

وبما أنّ الفترة الزمنية الأخيرة أقصر، ستكون المقاييس المضافة (مثل مجموع الخطوات أو عددها) أقل في المجموعة المقتطعة بسبب قصر المدة الزمنية فقط.

إذا مشى المستخدم بوتيرة ثابتة تبلغ 100 خطوة في الدقيقة خلال هذا النطاق الكامل الذي يبلغ 12 دقيقة:

المجموعة 1 (من الساعة 10:00 إلى الساعة 10:05): 500 خطوة (5 دقائق × 100 خطوة/دقيقة)
المجموعة 2 (من الساعة 10:05 إلى الساعة 10:10): 500 خطوة (5 دقائق × 100 خطوة/دقيقة)
المجموعة 3 (من الساعة 10:10 إلى الساعة 10:12): 200 خطوة (دقيقتان × 100 خطوة/دقيقة)

مثال على ردّ من واجهة برمجة التطبيقات يعرض الترتيب

بما أنّ واجهة برمجة التطبيقات تعرض النتائج بترتيب زمني عكسي، يظهر الجزء المقتطع من الحزمة كأول عنصر في القائمة المعروضة:

{
  "rollupDataPoints": [
    {
      "startTime": "2026-08-20T10:10:00Z",
      "endTime": "2026-08-20T10:12:00Z",
      "steps": {
        "countSum": "200"
      }
    },
    {
      "startTime": "2026-08-20T10:05:00Z",
      "endTime": "2026-08-20T10:10:00Z",
      "steps": {
        "countSum": "500"
      }
    },
    {
      "startTime": "2026-08-20T10:00:00Z",
      "endTime": "2026-08-20T10:05:00Z",
      "steps": {
        "countSum": "500"
      }
    }
  ]
}

حجم نافذة التجميع ودرجة دقة مساحة التخزين الأساسية

على الرغم من أنّ نقطة النهاية rollUp تقبل أي windowSize ثانية أو أكثر، تسجّل أنواع البيانات المختلفة القياسات وتحتفظ بها بمعدّلات أخذ عيّنات أو مدة فواصل زمنية مختلفة في مساحة التخزين الأساسية. على سبيل المثال، يتم عادةً تسجيل مقاييس النشاط البدني القابل للارتداء، مثل steps وdistance وactive-minutes وactive-energy-burned، على فترات زمنية مدتها دقيقة واحدة (60s).

عند تجميع أنواع بيانات الفواصل الزمنية، تضع نقطة النهاية rollUp كل نقطة بيانات مسجّلة في الحزمة التي تحتوي على startTime لنقطة البيانات. لا تقسم واجهة برمجة التطبيقات بيانات الفترات الزمنية أو تستكملها أو توزعها على حِزم الفترات الزمنية الفرعية.

إذا حدّدت قيمة windowSize أصغر من الفترة الزمنية لتخزين البيانات الأساسية (على سبيل المثال، طلب فترة زمنية مدتها 10 ثوانٍ للبيانات steps المخزَّنة على فترات زمنية مدتها دقيقة واحدة):

يتلقّى القسم الفرعي الأول الذي يتطابق مع startTime للفاصل الزمني (على سبيل المثال، من 10:00:00 إلى 10:00:10) إجمالي عدد الخطوات المتراكمة خلال الدقيقة (على سبيل المثال، جميع الخطوات الـ 100 المسجّلة خلال تلك الدقيقة).
ولا تتلقّى الأقسام الفرعية المتبقية ضمن تلك الدقيقة نفسها (من 10:00:10 إلى 10:00:20 ومن 10:00:20 إلى 10:00:30 وما إلى ذلك) أي نقاط بيانات، لأنّه لا تبدأ أي فترة زمنية ضمن تلك النوافذ.

وينتج عن ذلك بيانات "حادة" حيث تتركز قيمة الفترة الزمنية بأكملها في النافذة الفرعية الأولى.

للحصول على مجاميع موزَّعة بالتساوي وذات مغزى، اضبط دائمًا windowSize على مدة تساوي أو تزيد عن دقة التخزين الأساسية لنوع البيانات المستهدَف (على سبيل المثال، 60s أو أكثر لـ steps). لمعرفة دقة التخزين والحد الأدنى المقترَح لنافذة التجميع لكل نوع بيانات، راجِع أنواع البيانات في Google Health API.

تعديل بيانات صحة مستخدم

استخدِم نقطة النهاية patch لتعديل بيانات الصحة الخاصة بأحد المستخدمين.

تعدّل نقطة النهاية patch سجلاً حاليًا استنادًا إلى المعرّف المحدّد في عنوان URL للطلب. قدِّم معرّف نقطة بيانات تم إدراجها سابقًا. تستبدل واجهة برمجة التطبيقات السجلّ الحالي.

يمكن أيضًا تعديل الطوابع الزمنية للفاصل الزمني لنقطة البيانات (startTime وendTime) من خلال مالك السجلّ أو نقلها من منصات المصدر، مثل Health Connect. لمعرفة تفاصيل حول إمكانية تغيير الطابع الزمني، يُرجى الاطّلاع على دليل إدارة البيانات. للاطّلاع على مثال حول تعديل الطوابع الزمنية للفاصل الزمني، راجِع تعديل الطوابع الزمنية للفاصل الزمني للبيانات الحالية.

حالات استخدام معرّف نقطة البيانات

يُعدّ معرّف نقطة البيانات ضروريًا في السيناريوهات التالية:

التعديلات المستهدَفة: لتعديل مقياس معيّن، قدِّم معرّفه في طلب patch.
عمليات الحذف: يتيح الاحتفاظ بالمعرّف لتطبيقك حذف السجلّ لاحقًا باستخدام نقطة النهاية batchDelete.

في ما يلي مثال على تعديل مستخدم لقراءة نسبة الدهون بالجسم على ميزان يُسمى "HumanScale" من شركة "Scales R Us". قراءة نسبة الدهون الجديدة في الجسم للمستخدم هي% 20 بتاريخ 2026-03-10:

طلب

PATCH https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints/1234567890
Authorization: Bearer access-token
Content-Type: application/json

{
  "name": "users/me/dataTypes/body-fat/dataPoints/1234567890",
  "dataSource": {
    "recordingMethod": "ACTIVELY_MEASURED",
    "device": {
      "formFactor": "SCALE",
      "manufacturer": "Scales R Us",
      "displayName": "HumanScale"
    }
  },
  "bodyFat": {
    "sampleTime": {
      "physicalTime": "2026-03-10T10:00:00Z"
    },
    "percentage": 20
  }
}

الردّ

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4main.DataPoint",
    "name": "users/123456789/dataTypes/body-fat/dataPoints/1234567890",
    "dataSource": {
      "recordingMethod": "ACTIVELY_MEASURED",
      "device": {
        "formFactor": "SCALE",
        "manufacturer": "Scales R Us",
        "displayName": "HumanScale"
      },
      "application": {
        "googleWebClientId": "618308034039.apps.googleusercontent.com"
      },
      "platform": "GOOGLE_WEB_API"
    },
    "bodyFat": {
      "sampleTime": {
        "physicalTime": "2026-03-10T10:00:00Z"
      },
      "percentage": 20
    }
  }
}

تعديل الطوابع الزمنية لفواصل التحديث للبيانات الحالية

لتعديل الطوابع الزمنية للفاصل الزمني (startTime وendTime في حمولات REST JSON أو start_time وend_time في gRPC) لنقطة بيانات حالية، أرسِل طلب PATCH إلى معرّف الموارد المنتظم الخاص بنقطة البيانات. يمكن للمالك الأساسي أو من أنشأ السجلّ فقط تعديل حقوله. لا يمكن للتطبيقات تعديل نقاط البيانات التي لم تنشئها.

للحصول على معلومات أساسية حول إمكانية تغيير الطابع الزمني، والتعديلات الواردة من Health Connect، وتأثيرات التخزين المؤقت، راجِع دليل إدارة البيانات.

يوضّح المثال التالي تطبيقًا للمالك يعدّل الطوابع الزمنية للفاصل الزمني في سجلّ ترطيب حالي باستخدام نقطة النهاية patch:

طلب

PATCH https://health.googleapis.com/v4/users/me/dataTypes/hydration-log/dataPoints/4093039283164890826
Authorization: Bearer access-token
Content-Type: application/json

{
  "hydrationLog": {
    "interval": {
      "startTime": "2026-09-03T10:05:00Z",
      "endTime": "2026-09-03T10:19:59Z"
    },
    "amountConsumed": {
      "milliliters": 350
    }
  }
}

الردّ

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4.DataPoint",
    "name": "users/111111256096816351/dataTypes/hydration-log/dataPoints/4093039283164890826",
    "hydrationLog": {
      "interval": {
        "startTime": "2026-09-03T10:05:00Z",
        "endTime": "2026-09-03T10:19:59Z",
        "civilStartTime": {
          "date": {
            "year": 2026,
            "month": 9,
            "day": 3
          },
          "time": {
            "hours": 10,
            "minutes": 5
          }
        },
        "civilEndTime": {
          "date": {
            "year": 2026,
            "month": 9,
            "day": 3
          },
          "time": {
            "hours": 10,
            "minutes": 19,
            "seconds": 59
          }
        }
      },
      "amountConsumed": {
        "milliliters": 350
      }
    }
  }
}

تسجيل صنف من الطعام

لتسجيل وجبة، أرسِل طلب POST إلى نقطة النهاية nutrition-log dataPoints. يحتوي نص الطلب على DataPoint مع كائن nutritionLog. لمزيد من المعلومات، يُرجى الاطّلاع على دليل التغذية.

على سبيل المثال:

طلب

POST https://health.googleapis.com/v4/users/me/dataTypes/nutrition-log/dataPoints
Authorization: Bearer access-token
Content-Type: application/json

{
  "nutritionLog": {
    "interval": {
      "startTime": "2026-06-16T12:00:00Z",
      "endTime": "2026-06-16T12:30:00Z"
    },
    "foodDisplayName": "Banana",
    "mealType": "LUNCH",
    "energy": {
      "kcal": 105
    },
    "totalCarbohydrate": {
      "grams": 27
    },
    "totalFat": {
      "grams": 0.3
    }
  }
}

الردّ

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4.DataPoint",
    "name": "users/123456789/dataTypes/nutrition-log/dataPoints/567890",
    "dataSource": {
      "recordingMethod": "ACTIVELY_MEASURED",
      "platform": "GOOGLE_WEB_API"
    },
    "nutritionLog": {
      "interval": {
        "startTime": "2026-06-16T12:00:00Z",
        "startUtcOffset": "0s",
        "endTime": "2026-06-16T12:30:00Z",
        "endUtcOffset": "0s"
      },
      "energy": {
        "kcal": 105
      },
      "totalCarbohydrate": {
        "grams": 27
      },
      "totalFat": {
        "grams": 0.3
      },
      "mealType": "LUNCH",
      "foodDisplayName": "Banana"
    }
  }
}

حذف بيانات صحة المستخدم

استخدِم طريقة batchDelete لحذف مصفوفة من بيانات تطبيق Fitbit الخاصة بالمستخدم.

في ما يلي مثال على مستخدم سجّل نسبة الدهون بالجسم سابقًا باستخدام ميزان، ولكنه يريد حذف السجلّ. باستخدام user-id وdata-point-id من إجراء الإدراج الأصلي:

طلب

POST https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints:batchDelete
Authorization: Bearer access-token
Accept: application/json
content-length: 93

{
  "names": [
    "users/123456789/dataTypes/body-fat/dataPoints/1234567890"
  ]
}

الردّ

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4main.BatchDeleteDataPointsResponse"
  }
}

الاطّلاع على معلومات الجهاز

استخدِم نقطة النهاية list لاسترداد قائمة الأجهزة المقترنة بحساب أحد المستخدمين. ويشمل ذلك معلومات طراز الجهاز (deviceVersion) وآخر مرة تمت فيها مزامنة الجهاز مع تطبيق Google Health للأجهزة الجوّالة (lastSyncTime).

تكون معلومات المزامنة وإعدادات القائمة مفيدة في تحديد وحلّ مشاكل المزامنة أو استرجاع البيانات السابقة منذ آخر وقت تمت فيه المزامنة.

على سبيل المثال:

طلب

GET https://health.googleapis.com/v4/users/me/pairedDevices
Authorization: Bearer access-token
Accept: application/json

الردّ

{
  "pairedDevices": [
    {
      "name": "users/me/pairedDevices/123456",
      "deviceType": "TRACKER",
      "batteryStatus": "High",
      "batteryLevel": 88,
      "lastSyncTime": "2026-03-04T07:05:00Z",
      "deviceVersion": "Charge 6",
      "macAddress": "00:11:22:33:44:55",
      "features": [
        "STEPS",
        "HEART_RATE"
      ]
    }
  ]
}

الاستعلام عن البيانات السابقة

من المزايا الأساسية لواجهة Google Health API إمكانية تتبُّع أداء المستخدم ومراقبة مؤشرات صحته الحيوية على مدار فترات زمنية طويلة. يمكنك طلب بيانات المستخدمين منذ أن تم تسجيلها، ولا تفرض واجهة برمجة التطبيقات أي قيود على مقدار البيانات السابقة التي يمكن أن يستهلكها تطبيقك.

ومع ذلك، تظل الاستعلامات عن البيانات السابقة خاضعة لحدود المعدّل العادية. لإدارة استقرار النظام ومنع الأحجام الكبيرة من الحِمل، تستخدم Google Health API تقسيم الصفحات تلقائيًا مع أحجام صفحات خاصة بنقاط النهاية. يُرجى مراعاة الحدود والسلوك التاليَين:

تقسيم النتائج على عدّة صفحات تلقائيًا: إذا طلبت نطاقًا طويلاً من البيانات، ستعرض واجهة برمجة التطبيقات الصفحة الأولى فقط من النتائج التي تصل إلى الحد الأقصى لحجم الصفحة لنقطة النهاية هذه، بالإضافة إلى nextPageToken. يجب استخدام nextPageToken لطلب الصفحات اللاحقة.
أحجام الصفحات المتغيرة: تعتمد حدود التحديد على نقطة النهاية ونوع البيانات. بالنسبة إلى معظم أنواع البيانات، يبلغ الحد الأقصى لحجم الصفحة 10,000. ومع ذلك، بالنسبة إلى أنواع بيانات معيّنة، مثل exercise وsleep، يبلغ الحدّ الأقصى لحجم الصفحة التلقائي 25. على سبيل المثال، إذا طلب أحد العملاء جميع بيانات النوم خلال السنوات الـ 10 الماضية، ستعرض واجهة برمجة التطبيقات 25 جلسة نوم فقط في الصفحة الأولى.
القيود المفروضة على النطاق الزمني لعمليات التجميع: بالنسبة إلى نقاط نهاية تجميع البيانات (مثل rollUp وdailyRollUp)، يتم حصر النطاقات الزمنية لطلبات البحث استنادًا إلى نوع البيانات:
- نطاق زمني أقصاه 14 يومًا لكل من calories-in-heart-rate-zone وheart-rate وactive-minutes وtotal-calories
- نطاق أقصى يبلغ 90 يومًا لجميع أنواع البيانات المجمّعة الأخرى

استنادًا إلى حجم البيانات السابقة التي يحتاجها تطبيقك، سيتطلّب استرداد مجموعة البيانات بأكملها تقسيم الصفحات إلى أجزاء بالتسلسل. يجب مراعاة ذلك عند تصميم عملية مزامنة البيانات في تطبيقك.

لضمان تحقيق الأداء الأمثل وتجنُّب أخطاء واجهة برمجة التطبيقات، اتّبِع الإرشادات التالية عند طلب بيانات سابقة:

مزامنة البيانات على مراحل (التحميل السريع مقابل التشغيل على البارد)

التحميل "السريع" الأوّلي: يتم جلب وعرض بيانات آخر 7 إلى 14 يومًا فقط خلال تسلسل التحميل الأساسي. يضمن ذلك أن يرى المستخدمون البيانات على الفور بدون انتظار الاستعلامات التي تستغرق وقتًا طويلاً.
التحميل "البارد" في الخلفية: تفويض عملية استرجاع البيانات السابقة إلى قائمة انتظار غير متزامنة ذات أولوية أقل أو عملية في الخلفية بعد عرض واجهة المستخدم الأساسية

تقسيم طلب البحث إلى أجزاء للتجميع

بما أنّ نقاط نهاية التجميع والتجميع اليومي تفرض حدًا أقصى للنطاق الزمني (14 أو 90 يومًا حسب نوع البيانات)، عليك تقسيم طلبات البحث الكبيرة الخاصة بالتجميع السابق إلى فواصل زمنية أصغر ومتسلسلة ضمن هذه الحدود.
يمكنك معالجة الطلبات الفرعية هذه على شكل دفعات أو تسلسل بشكل آمن للالتزام بحدود التنفيذ المتزامن والحفاظ على مؤشرات التقدّم الثابتة في واجهة المستخدم.

الاستفادة من عمليات التجميع المُسبقة

إعادة هيكلة لوحات البيانات الخاصة بالنظرة العامة ومخططات المؤشرات لاستخدام نقاط نهاية مجمّعة مسبقًا وملخّصة (مثل DailyRollUpDataPoints)، ما سيؤدي إلى تقليل الحمل الزائد للحوسبة بشكل كبير في الخلفية ووقت نقل البيانات إلى العميل عبر الشبكة

معالجة الأخطاء المرنة (عمليات إعادة المحاولة الذكية)

يجب تنفيذ معالجة صارمة للتراجع الأسي عند مواجهة حدود المعدّل (429 Too Many Requests) ومهلات بوابة الخادم (504 Gateway Timeout)، وعدم إعادة محاولة إرسال الحِزم الكبيرة التي تعذّر إرسالها على الفور. تؤدي عمليات إعادة المحاولة الفورية إلى زيادة الازدحام في الخلفية وتفاقم تدهور أداء النظام.

مكتبات العملاء

الفلاتر

نقاط النهاية تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

اتّفاقيات REST API

مَعلمات طلب البحث

نص الطلب

حالة الاستخدام المختلطة

نظرة سريعة على الاختلافات الرئيسية

التواريخ

العناوين

فهرس مهام واجهة برمجة التطبيقات

الحصول على رقم تعريف مستخدم Fitbit أو Google

طلب

الردّ

الحصول على بيانات مفصّلة أو بيانات خلال اليوم تم جمعها على مدار يوم كامل

طلب

الردّ

الحصول على عرض متوافق لبيانات الفترات

قائمة غير منسَّقة

تمت التسوية

تصفية البيانات

الفلترة حسب مجموعة مصادر البيانات

فلترة البيانات حسب وقت بدء مدني لفترة زمنية

طلب

الردّ

فلترة البيانات حسب الوقت الفعلي لملاحظة نموذجية

طلب

الردّ

الفلترة والتجميع حسب مجموعة مصادر البيانات

مجموعات مصادر البيانات المتوافقة

طلب

الردّ

طلب

الردّ

طلب

الردّ

تجميع نقاط البيانات على مدار فترة زمنية

طلب

الردّ

تجميع البيانات على مدار يوم واحد أو عدة أيام

طلب

الردّ

تصنيف البيانات إلى مجموعات عندما لا يكون النطاق مضاعفًا لحجم النافذة

طريقة عمل التقسيم إلى مجموعات

السيناريو: نطاق 12 دقيقة مع فترة زمنية مدتها 5 دقائق

التأثير في القيم المجمّعة

مثال على ردّ من واجهة برمجة التطبيقات يعرض الترتيب

حجم نافذة التجميع ودرجة دقة مساحة التخزين الأساسية

تعديل بيانات صحة مستخدم

حالات استخدام معرّف نقطة البيانات

طلب

الردّ

تعديل الطوابع الزمنية لفواصل التحديث للبيانات الحالية

طلب

الردّ

تسجيل صنف من الطعام

طلب

الردّ

حذف بيانات صحة المستخدم

طلب

الردّ

الاطّلاع على معلومات الجهاز

طلب

الردّ

الاستعلام عن البيانات السابقة

مزامنة البيانات على مراحل (التحميل السريع مقابل التشغيل على البارد)

تقسيم طلب البحث إلى أجزاء للتجميع

الاستفادة من عمليات التجميع المُسبقة

معالجة الأخطاء المرنة (عمليات إعادة المحاولة الذكية)

نقاط النهاية