Endpunkte

Auf dieser Seite finden Sie eine Übersicht über die REST API-Konventionen sowie einen Index häufiger Google Health API-Aufgaben und Beispiele für jede Aufgabe.

REST API-Konventionen

Die Google Health API folgt den Google API Improvement Proposals (AIP) Standards, insbesondere AIP-127 (HTTP and gRPC Transcoding) und AIP-131 bis AIP-135 (Standard Methods). In diesen Standards wird definiert, wie Daten aus einer Proto-Nachricht einer HTTP-Anfrage zugeordnet werden.

Suchparameter

Suchparameter werden verwendet, wenn die Daten Teil der URL sind. Dies gilt hauptsächlich für GET-Anfragen (Abrufen einer Ressource) oder LIST-Anfragen (Filtern/Paginierung), wird aber auch für DELETE-Vorgänge verwendet.

  • Platzierung: Wird nach einem ? an die URL angehängt.
  • Syntax: Schlüssel/Wert-Paare, getrennt durch &.
  • Mapping: Jedes Feld in der Anfragenachricht, das nicht Teil der URL Pfadvorlage ist, wird einem Suchparameter zugeordnet.
  • Bestens geeignet für: Einfache Typen (Strings, Ganzzahlen, Aufzählungen) und wiederholte Felder.

Beispielsyntax:

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"

Anfragetext

Der Anfragetext wird verwendet, wenn die Daten den Status einer Ressource ändern oder zu groß für eine URL sind. Der Text ist in der Regel eine JSON-Darstellung der Ressource selbst. Wird in der Regel für POST-, PATCH- und PUT-Vorgänge verwendet.

  • Platzierung: Innerhalb der HTTP-Nutzlast (nicht in der URL sichtbar).
  • Syntax: Als JSON-Objekt formatiert.
  • Mapping: In der google.api.http Annotation definiert.
    • body: "*" bedeutet, dass die gesamte Nachricht der Text ist.
    • body: "resource_name" bedeutet, dass nur ein bestimmtes Feld im Proto der Text ist.
  • Bestens geeignet für: Komplexe Objekte, verschachtelte Nachrichten und vertrauliche Daten.

Beispielsyntax:

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"
}

Der Hybridfall

Bei einer AIP-134-konformen Update-Methode oder einem PATCH-Vorgang werden beide verwendet. Die URL enthält den Ressourcennamen, der Text enthält die aktualisierten Ressourcendaten und ein Suchparameter (in der Regel update_mask) gibt an, welche Felder geändert werden sollen.

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

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

Wichtige Unterschiede auf einen Blick

Funktion Suchparameter Anfragetext
AIP-Anleitung Wird für Such-, Filter- und Lesevorgänge verwendet. Wird für Schreibvorgänge verwendet.
Sichtbarkeit Im Browserverlauf und in Serverlogs sichtbar. In der URL ausgeblendet.
Komplexität Beschränkt auf flache oder wiederholte Strukturen. Unterstützt tief verschachtelte JSON-Objekte.
Codierung Muss URL-codiert sein (z. B. werden Leerzeichen zu %20). Standard-JSON-Codierung.

Daten

Alle Daten in der Google Health API werden im Format YYYY-MM-DD angezeigt. Die Nutrition API unterstützt den ISO 8601-Standard für Datumswerte mit den folgenden Bedingungen:

  • Ein vierstelliges Jahr YYYY
  • Jahreswerte im Bereich von 0000 bis 9999
  • Keine Erzwingung von Einschränkungen für das Startdatum, die durch den ISO 8601-Standard oder eine andere Epoche impliziert werden

Header

Für die Ausführung der Google Health API-Endpunkte müssen die entsprechenden Header und das Zugriffstoken verwendet werden. Der folgende Header wird sowohl für GET- als auch für POST-Anfragen empfohlen:

Authorization: Bearer access-token
Accept: application/json

Index der API-Aufgaben

In diesem Abschnitt finden Sie einen Index häufiger Google Health API-Aufgaben und Beispiele für jede Aufgabe.

Fitbit- oder Google-Nutzer-ID abrufen

Nachdem ein Nutzer über Google OAuth 2.0 zugestimmt hat, enthält die Tokenantwort nicht die Fitbit- oder Google-Nutzer-ID. Rufen Sie den getIdentity Endpunkt auf, um die Nutzer-ID zu erhalten. getIdentity gibt sowohl die alte Fitbit-Nutzer-ID als auch die Google-Nutzer-ID zurück.

Wir empfehlen, dass Sie den Endpunkt getIdentity aufrufen und beide Nutzer-IDs speichern, sobald ein neuer Nutzer über OAuth zustimmt. So sorgen Sie für Vorwärts- und Rückwärtskompatibilität in Ihrer Integration.

Beispiel:

Anfrage

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

Antwort

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

Intraday- oder detaillierte Daten abrufen, die im Laufe eines Tages erhoben wurden

Verwenden Sie den list Endpunkt für einen bestimmten Datentyp, um Intraday- oder detaillierte Daten abzurufen, die im Laufe des Tages in unterstützten Intervallen für diesen Datentyp erhoben wurden.

Beispiel:

Anfrage

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

Antwort

{
  "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"
}

Daten nach der zivilen Startzeit eines Intervalls filtern

Verwenden Sie den Endpunkt list mit einem filter-Parameter, um Daten nach ziviler Zeit oder einem Intervall zu filtern.

Beispiel:

Anfrage

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

Antwort

{
  "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"
}

Daten nach der physischen Zeit einer Beispielbeobachtung filtern

Verwenden Sie den Endpunkt list mit einem filter-Parameter, um Daten nach der physischen Zeit einer Beispielbeobachtung zu filtern.

Beispiel:

Anfrage

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

Antwort

{
  "dataPoints": [
    {
      "name": "users/2515055256096816351/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": ""
}

Daten nach Datenquellen wie Wearables filtern

Verwenden Sie den reconcile Endpunkt, um Daten für eine bestimmte "Datenquellenfamilie" abzurufen. Geben Sie dazu den Parameter dataSourceFamily als Suchparameter an.

In der folgenden Tabelle werden die unterstützten dataSourceFamily-Optionen beschrieben:

Option Beschreibung
users/me/dataSourceFamilies/all-sources Standardwert. Enthält Daten aus allen verfügbaren Datenquellen.
users/me/dataSourceFamilies/google-wearables Enthält Daten von Google- und Fitbit-Trackern (z. B. Fitbit-Tracker und Pixel Watch). Manuell erfasste Daten werden ausgeschlossen.
users/me/dataSourceFamilies/google-sources Enthält selbst erhobene Google-Daten, z. B. Daten von Trackern und manuell erfasste Daten.

Hier ein Beispiel für das Filtern von Schlafdaten, die nach dem 3. März 2026 mit einem Tracker erfasst wurden:

Anfrage

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

Antwort

{
  "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": ""
}

Datenpunkte über einen Zeitraum aggregieren

Verwenden Sie den rollUp Endpunkt, um die Aggregation von Datenpunkten basierend auf einem Fenster in Sekunden über den datetime Bereich basierend auf der physischen Zeit des Nutzers (in UTC) zurückzugeben.

Wenn Sie den Endpunkt rollUp aufrufen, müssen Sie den Anfragetext angeben, der den erforderlichen Zeitraum in der zivilen Zeit des Nutzers darstellt. Beispiel:

Anfrage

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": "30s"
}

Antwort

{
  "rollupDataPoints": [
    {
      "startTime": "2026-02-17T17:55:00Z",
      "endTime": "2026-02-17T17:55:30Z",
      "steps": {
        "countSum": "41"
      }
    },
    {
      "startTime": "2026-02-17T17:54:00Z",
      "endTime": "2026-02-17T17:54:30Z",
      "steps": {
        "countSum": "31"
      }
    },
...
  ]
}

Daten über einen oder mehrere Tage aggregieren

Der dailyRollUp Endpunkt sollte verwendet werden, wenn Sie Daten über einen oder mehrere Tage aggregieren möchten, die als windowSize bezeichnet werden. Geben Sie im Anfragetext den geschlossenen-offenen zivilen Zeitraum für das erforderliche Intervall an. Je nach Datentyp erhalten Sie entweder die Summe oder den Durchschnitt über das Intervall.

Beispiel:

Anfrage

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
}

Antwort

{
  "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"
      }
    }
  ]
}

Gesundheitsdaten eines Nutzers einfügen oder aktualisieren

Verwenden Sie den patch Endpunkt, um die Fitbit App-Daten eines Nutzers einzufügen oder zu aktualisieren.

Hier ein Beispiel, bei dem ein Nutzer seinen Körperfettanteil auf einer Waage namens „HumanScale“ des Unternehmens „Scales R Us“ erfasst hat. Der neue Körperfettanteil des Nutzers beträgt am 10. März 2026 20 %.

Anfrage

PATCH https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints/1234567890
Authorization: Bearer access-token
content-length: 329

{
  "name": "bodyFatName",
  "dataSource": {

    "recordingMethod": "ACTIVELY_MEASURED",
    "device": {
      "formFactor": "SCALE",
      "manufacturer": "Scales R Us",
      "displayName": "HumanScale"
    }
  },
  "bodyFat": {
    "sampleTime": {
      "physicalTime": "2026-03-10T10:00:00Z"
    },
    "percentage": 20
  }
}

Antwort

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4main.DataPoint",
    "name": "users/2515055256096816351/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
    }
  }
}

Lebensmittel protokollieren

Senden Sie eine POST-Anfrage an den Endpunkt nutrition-log dataPoints, um ein Lebensmittel zu protokollieren. Der Anfragetext enthält einen DataPoint mit einem nutritionLog-Objekt. Weitere Informationen finden Sie im Leitfaden zur Nutrition API.

Beispiel:

Anfrage

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
    }
  }
}

Antwort

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4.DataPoint",
    "name": "users/2515055256096816351/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"
    }
  }
}

Gesundheitsdaten von Nutzern löschen

Verwenden Sie die batchDelete Methode, um ein Array von Fitbit App-Daten eines Nutzers zu löschen.

Hier ein Beispiel, bei dem ein Nutzer zuvor seinen Körperfettanteil auf einer Waage erfasst hat, den Eintrag aber löschen möchte. Verwenden Sie die user-id und data-point-id aus der ursprünglichen Einfügeaktion:

Anfrage

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/2515055256096816351/dataTypes/body-fat/dataPoints/1234567890"
  ]
}

Antwort

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

Geräteinformationen abrufen

Verwenden Sie den list Endpunkt, um die Liste der Geräte abzurufen, die mit dem Konto eines Nutzers verknüpft sind. Dazu gehören die Modellinformationen des Geräts (deviceVersion) und der Zeitpunkt der letzten Synchronisierung mit der Google Health Mobile App (lastSyncTime).

Die Listenkonfiguration und die Synchronisierungsinformationen sind nützlich, um Synchronisierungsprobleme zu beheben oder Verlaufsdaten seit der letzten Synchronisierung abzurufen.

Beispiel:

Anfrage

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

Antwort

{
  "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"
      ]
    }
  ]
}

Verlaufsdaten abfragen

Einer der Hauptvorteile der Google Health API ist die Möglichkeit, die Leistung eines Nutzers zu verfolgen und seine Vitalparameter über lange Zeiträume zu beobachten. Sie können die Daten eines Nutzers so weit zurück abfragen, wie sie erfasst wurden. Die API unterliegt keinen Einschränkungen hinsichtlich der Menge an Verlaufsdaten, die Ihre Anwendung verwenden kann.

Die Abfrage von Verlaufsdaten unterliegt jedoch weiterhin den Standard Ratenlimits. Um die Systemstabilität zu gewährleisten und übermäßige Nutzlasten zu vermeiden, verwendet die Google Health API die automatische Paginierung mit endpunktspezifischen Seitengrößen. Beachten Sie die folgenden Grenzen und Verhaltensweisen:

  • Automatische Paginierung: Wenn Sie einen langen Zeitraum abfragen, gibt die API nur die erste Seite der Ergebnisse bis zur Obergrenze der Seitengröße für diesen Endpunkt zurück, zusammen mit einem nextPageToken. Sie müssen das nextPageToken verwenden, um nachfolgende Seiten anzufordern.
  • Variable Seitengrößen: Die Obergrenzen hängen vom Endpunkt und Datentyp ab. Für die meisten Datentypen ist die Seitengröße auf maximal 10.000 begrenzt. Für bestimmte Datentypen wie exercise und sleep, ist die Standard- und maximale Seitengröße jedoch auf 25 begrenzt. Wenn ein Client beispielsweise alle Schlafdaten der letzten 10 Jahre anfordert, gibt die API auf der ersten Seite trotzdem nur 25 Schlafsitzungen zurück.
  • Einschränkungen für den Zeitraum für Rollups:Für Endpunkte für Daten-Rollups und -Aggregationen (z. B. rollUp und dailyRollUp) sind die Abfragezeiträume je nach Datentyp eingeschränkt:
    • Ein maximaler Zeitraum von 14 Tagen für calories-in-heart-rate-zone, heart-rate, active-minutes, und total-calories.
    • Ein maximaler Zeitraum von 90 Tagen für alle anderen Rollup-Datentypen.

Je nach Menge der Verlaufsdaten, die Ihre Anwendung benötigt, müssen Sie die Seiten sequenziell durchgehen, um das gesamte Dataset abzurufen. Berücksichtigen Sie dies beim Entwerfen des Datenabgleichsprozesses Ihrer Anwendung.

Beachten Sie die folgenden Richtlinien, wenn Sie Verlaufsdaten abfragen, um eine optimale Leistung zu erzielen und API-Fehler zu vermeiden:

Phasensynchronisierung von Daten (Hot- vs. Cold-Load)

  • Erster „Hot“-Load: Rufen Sie während der primären Ladefolge nur die Daten der letzten 7 bis 14 Tage ab und rendern Sie sie. So können Nutzer Daten sofort sehen, ohne auf lange Abfragen warten zu müssen.
  • „Cold“-Load im Hintergrund: Delegieren Sie den Abruf älterer Verlaufsdaten an eine asynchrone Warteschlange mit niedrigerer Priorität oder einen Hintergrundprozess, nachdem die primäre Benutzeroberfläche gerendert wurde.

Abfrage-Chunking für die Aggregation

  • Da für Rollup- und Daily-Rollup-Endpunkte eine maximale Zeitraumbegrenzung gilt (je nach Datentyp 14 oder 90 Tage), müssen Sie große Abfragen zur Verlaufsaggregation in kleinere, sequenzielle Intervalle innerhalb dieser Grenzen aufteilen.
  • Führen Sie diese Unterabfragen im Batch-Modus oder sequenziell aus, um die Grenzwerte für die Parallelität einzuhalten und gleichmäßige Fortschrittsindikatoren auf der Benutzeroberfläche zu gewährleisten.

Vorab aggregierte Rollups nutzen

Strukturieren Sie Übersichts-Dashboards und Trenddiagramme so um, dass vorab aggregierte Zusammenfassungsendpunkte wie DailyRollUpDataPoints verwendet werden. Dadurch werden der Rechenaufwand im Backend und die Zeit für die Netzwerkübertragung zum Client drastisch reduziert.

Robuste Fehlerbehandlung (intelligente Wiederholungen)

  • Implementieren Sie eine strenge exponentielle Backoff-Verarbeitung, wenn Raten limits (429 Too Many Requests) und Server-Gateway-Timeouts (504 Gateway Timeout) auftreten. Wiederholen Sie große, fehlgeschlagene Nutzlasten niemals sofort. Sofortige Wiederholungen führen zu einer Überlastung des Backends und zu einer Verschlechterung des Systems.