Best Practices

Autorisierung

Alle Anfragen an die Google Fotos APIs müssen von einem authentifizierten Nutzer autorisiert werden.

Die Details dieses Autorisierungsablaufs für OAuth 2.0 hängen davon ab, welche Art von Anwendung du schreibst. Die folgende allgemeine Vorgehensweise gilt für alle Arten von Anwendungen:

  1. So bereiten Sie sich auf den Autorisierungsprozess vor:
    • Registrieren Sie Ihre Anwendung über die Google API Console.
    • Aktivieren Sie die Google Fotos APIs und rufen Sie OAuth-Details wie eine Client-ID und ein Client-Secret ab. Weitere Informationen finden Sie unter Einstieg.
  2. Um auf Nutzerdaten zuzugreifen, sendet die Anwendung eine Anfrage an Google, um einen bestimmten Zugriffsbereich zu erhalten.
  3. Dem Nutzer wird von Google ein Zustimmungsbildschirm angezeigt, auf dem er gebeten wird, die Anwendung dazu zu autorisieren, einige seiner Daten abzufragen.
  4. Wenn der Nutzer zustimmt, stellt Google der Anwendung ein Zugriffstoken zur Verfügung, das nach kurzer Zeit abläuft.
  5. Die Anwendung fordert Nutzerdaten an, wobei das Zugriffstoken an die Anfrage angehängt wird.
  6. Stellt Google fest, dass die Anfrage und das Token gültig sind, werden die angeforderten Daten zurückgegeben.

Informationen dazu, welche Bereiche für Ihre Anwendung geeignet sind, finden Sie unter Autorisierungsbereiche.

Bei einigen Anwendungstypen sind zusätzliche Schritte erforderlich, z. B. die Verwendung von Aktualisierungstoken zum Abrufen neuer Zugriffstoken. Weitere Informationen über die Abläufe für die unterschiedlichen Anwendungstypen finden Sie im Hilfeartikel Mit OAuth 2.0 auf Google APIs zugreifen.

Caching

Daten auf dem neuesten Stand halten.

Wenn Sie Medien wie Miniaturansichten, Fotos oder Videos aus Leistungsgründen vorübergehend speichern müssen, dürfen Sie sie gemäß unseren Nutzungsrichtlinien nicht länger als 60 Minuten im Cache speichern.

Außerdem sollten Sie keine baseUrls speichern, da diese nach etwa 60 Minuten ablaufen.

Medienelement-IDs und Album-IDs, mit denen Inhalte in der Mediathek eines Nutzers eindeutig identifiziert werden können, sind von der Caching-Einschränkung ausgenommen. Sie können diese IDs unbegrenzt speichern (vorbehaltlich der Datenschutzerklärung Ihrer App). Verwende die Medienelement-IDs und Album-IDs, um über die entsprechenden Endpunkte wieder zugängliche URLs und Daten abzurufen. Weitere Informationen findest du unter Medienelement abrufen oder Alben auflisten.

Wenn Sie viele Medienelemente aktualisieren möchten, ist es möglicherweise effizienter, die Suchparameter zu speichern, mit denen die Medienelemente zurückgegeben wurden, und die Abfrage noch einmal zu senden, um die Daten neu zu laden.

SSL-Zugriff

Für alle Webdienstanfragen der Google Fotos APIs mit der folgenden URL ist HTTPS erforderlich:

https://photoslibrary.googleapis.com/v1/service/output?parameters

Anfragen über HTTP werden abgelehnt.

Fehlerbehandlung

Informationen zum Umgang mit von der API zurückgegebenen Fehlern finden Sie unter Fehlerbehandlung für Cloud APIs.

Fehlgeschlagene Anfragen wiederholen

Bei 5xx-Fehlern sollten Clients wie unter Exponentieller Backoff beschrieben mit exponentiellem Backoff einen neuen Versuch starten. Die Mindestverzögerung sollte 1 s Sekunden betragen, sofern nicht anders angegeben.

Bei 429-Fehlern kann der Client den Versuch mit einer Verzögerung von mindestens 30s wiederholen. Bei allen anderen Fehlern ist keine Wiederholung möglich. Prüfen Sie, ob Ihre Anfrage idempotent ist, und lesen Sie die Fehlermeldung, um weitere Informationen zu erhalten.

Exponentielle Backoffs

In seltenen Fällen kann beim Ausführen Ihrer Anfrage ein Fehler auftreten.Möglicherweise erhalten Sie einen HTTP-Antwortcode 4XX oder 5XX oder die TCP-Verbindung zwischen Ihrem Client und dem Google-Server bricht ab. Oft lohnt es sich, die Anfrage noch einmal zu senden. Die Folgeanfrage kann erfolgreich sein, wenn die ursprüngliche Anfrage fehlgeschlagen ist. Es ist jedoch wichtig, keine Schleife zu verwenden und wiederholt Anfragen an die Google-Server zu senden. Dieses Looping-Verhalten kann das Netzwerk zwischen Ihrem Kunden und Google überlasten und Probleme für viele Parteien verursachen.

Ein besserer Ansatz ist es, wiederholte Versuche in immer größeren Abständen durchzuführen. Normalerweise wird die Verzögerung bei jedem Versuch um einen Multiplikator erhöht. Dieser Ansatz wird als exponentieller Backoff bezeichnet.

Außerdem sollten Sie darauf achten, dass sich in der Aufrufabfolge der Anwendung kein Code zum Wiederholen befindet, der zu wiederholten Anfragen in schneller Folge führt.

Vernünftige Nutzung von Google APIs

Schlecht konzipierte API-Clients können sowohl das Internet als auch die Google-Server stärker belasten als nötig. Dieser Abschnitt enthält einige Best Practices für Clients der APIs. Wenn Sie diese Best Practices befolgen, lässt sich vermeiden, dass Ihre Anwendung aufgrund von unbeabsichtigtem Missbrauch der APIs blockiert wird.

Synchrone Anfragen

Eine große Anzahl synchronisierter Anfragen an die APIs von Google kann wie ein DDoS-Angriff (Distributed Denial of Service) auf die Infrastruktur von Google aussehen und entsprechend behandelt werden. Um dies zu vermeiden, sollten Sie dafür sorgen, dass API-Anfragen nicht zwischen Clients synchronisiert werden.

Angenommen, Sie haben eine Anwendung, die die Uhrzeit in der aktuellen Zeitzone anzeigt. Diese Anwendung stellt wahrscheinlich einen Wecker im Clientbetriebssystem ein, der es zu Beginn der Minute weckt, damit die angezeigte Uhrzeit aktualisiert werden kann. Die Anwendung darf im Rahmen der Verarbeitung, die mit dieser Benachrichtigung verbunden ist, keine API-Aufrufe ausführen.

API-Aufrufe als Reaktion auf einen festen Wecker sind nicht empfehlenswert, da die API-Aufrufe dann auf den Beginn der Minute synchronisiert werden, auch zwischen verschiedenen Geräten, anstatt gleichmäßig über die Zeit verteilt zu werden. Eine schlecht konzipierte Anwendung, die dies tut, führt zu einem Anstieg des Traffics um das Sechzigfache des Normalwerts zu Beginn jeder Minute.

Stattdessen kann ein zweiter Wecker auf eine zufällig ausgewählte Uhrzeit eingestellt werden. Wenn dieser zweite Alarm ausgelöst wird, ruft die Anwendung alle erforderlichen APIs auf und speichert die Ergebnisse. Um die Anzeige zu Beginn der Minute zu aktualisieren, verwendet die Anwendung zuvor gespeicherte Ergebnisse, anstatt die API noch einmal aufzurufen. Bei dieser Vorgehensweise werden API-Aufrufe gleichmäßig über eine Zeitspanne hinweg verteilt. Außerdem verzögern die API-Aufrufe das Rendering nicht, wenn das Display aktualisiert wird.

Neben dem Beginn der Minute sollten Sie auch den Beginn einer Stunde und den Beginn eines jeden Tages um Mitternacht nicht für das Targeting verwenden.