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

نقاط النهاية

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

اتّفاقيات REST API

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

بعد موافقة المستخدم من خلال بروتوكول OAuth 2.0 من Google، لن يتضمّن رد الرمز المميز معرّف مستخدم 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 التالي بيانات النوم المسجّلة بواسطة جهاز التتبُّع لليوم التالي لتاريخ 2026-03-03:

طلب

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 دقيقة مع فترة windowSize تبلغ 5 دقائق:

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 بتاريخ 10-03-2026:

طلب

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 لنقطة بيانات فاصل زمني حالية، أرسِل طلب 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 دقائق

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

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

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

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

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

طلب

الردّ

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

طلب

الردّ

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

طلب

الردّ

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

طلب

الردّ

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

طلب

الردّ

طلب البيانات السابقة

مزامنة البيانات على مراحل (التحميل السريع مقابل التحميل البطيء)

تقسيم طلب البحث لتجميع البيانات

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

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

نقاط النهاية