Best Practices

Autorisierung

Alle Anfragen an die Google Photos Library API müssen von einem authentifizierten Nutzer autorisiert werden.

Die Details des Autorisierungsverfahrens für OAuth 2.0 unterscheiden sich geringfügig, je nachdem, welche Art von Anwendung Sie schreiben. Das folgende allgemeine Verfahren gilt für alle Anwendungstypen:

1. Bereiten Sie den Autorisierungsprozess so vor:
   • Registrieren Sie Ihre Anwendung mit der Google API Console.
   • Aktiviere die Library API und rufe OAuth-Details wie eine Client-ID und einen Clientschlüssel ab. Weitere Informationen finden Sie unter Erste Schritte.
2. Für den Zugriff auf Nutzerdaten wird von der Anwendung ein bestimmter Zugriffsbereich bei Google angefragt.
3. Dem Nutzer wird ein Zustimmungsbildschirm angezeigt, auf dem er gebeten wird, die Anwendung zu autorisieren, einige seiner Daten anzufordern.
4. Wenn der Nutzer zustimmt, stellt Google der Anwendung ein Zugriffstoken zur Verfügung, das nach einer kurzen Zeit abläuft.
5. Die Anwendung stellt eine Anfrage für die Nutzerdaten und hängt das Zugriffstoken an die Anfrage an.
6. Wenn Google feststellt, dass die Anfrage und das Token gültig sind, werden die angeforderten Daten zurückgegeben.

Unter Autorisierungsbereiche können Sie feststellen, welche Bereiche für Ihre Anwendung geeignet sind.

Der Prozess für einige Anwendungstypen umfasst zusätzliche Schritte, z. B. die Verwendung von Aktualisierungstokens zum Abrufen neuer Zugriffstokens. Ausführliche Informationen zu den Abläufen für verschiedene Anwendungstypen finden Sie unter Mit OAuth 2.0 auf Google APIs zugreifen.

Hinweis: Angesichts der Sicherheitsaspekte, die eine korrekte Implementierung mit sich bringt, empfehlen wir dringend, für die Interaktion mit den OAuth 2.0-Endpunkten von Google OAuth 2.0-Bibliotheken zu verwenden. Es empfiehlt sich, von anderen Anbietern gut Debugging-Code zu verwenden, und hilft Ihnen dabei, sich und Ihre Nutzer zu schützen. Weitere Informationen findest du unter OAuth 2.0-Clientbibliotheken.

Caching

Halten Sie die Daten aktuell.

Wenn du Medien wie Thumbnails, Fotos oder Videos aus Leistungsgründen vorübergehend speichern musst, solltest du sie gemäß unseren Nutzungsrichtlinien nicht länger als 60 Minuten im Cache speichern.

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

Medienelement-IDs und Album-IDs, die Inhalte in der Mediathek eines Nutzers eindeutig identifizieren, sind von der Caching-Einschränkung ausgenommen. Sie können diese IDs gemäß der Datenschutzerklärung Ihrer App unbegrenzt speichern. Verwenden Sie Medienelement-IDs und Album-IDs, um zugängliche URLs und Daten mithilfe der entsprechenden Endpunkte noch einmal abzurufen. Weitere Informationen finden Sie unter Medienelement abrufen oder Alben auflisten.

Wenn viele Medienelemente aktualisiert werden müssen, ist es möglicherweise effizienter, die Suchparameter, die die Medienelemente zurückgegeben haben, zu speichern und die Abfrage noch einmal zu senden, um die Daten neu zu laden.

SSL-Zugriff

HTTPS ist für alle Library API-Webdienstanfragen über die folgende URL 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 in Cloud APIs.

Fehlgeschlagene Anfragen wiederholen

Clients sollten den Vorgang nach 5xx-Fehlern mit exponentiellem Backoff wiederholen, wie unter Exponentieller Backoff beschrieben. Die minimale Verzögerung sollte 1 s betragen, sofern nicht anders angegeben.

Bei 429-Fehlern kann der Client den Vorgang mit einer Mindestverzögerung von 30s wiederholen. Bei allen anderen Fehlern ist die Wiederholung möglicherweise nicht anwendbar. Prüfen Sie, ob Ihre Anfrage idempotent ist. Lesen Sie sich die Fehlermeldung als Orientierungshilfe durch.

Exponentielle Backoffs

In seltenen Fällen kann bei der Verarbeitung Ihrer Anfrage ein Fehler auftreten.Sie erhalten möglicherweise einen HTTP-Antwortcode 4XX oder 5XX oder die TCP-Verbindung zwischen Ihrem Client und dem Google-Server kann fehlschlagen. Oft lohnt es sich, die Anfrage noch einmal zu senden. Die Folgeanfrage ist möglicherweise erfolgreich, wenn die ursprüngliche Anfrage fehlgeschlagen ist. Es ist jedoch wichtig, keine Schleifen zu senden, da wiederholt Anfragen an die Server von Google gestellt werden. Dieses Verhalten kann eine Überlastung des Netzwerks zwischen Ihrem Client und Google verursachen und für viele Parteien zu Problemen führen.

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 multiplikativen Faktor erhöht. Dieser Ansatz wird als exponentieller Backoff bezeichnet.

Sie sollten auch darauf achten, dass sich weiter oben in der Anwendungsaufrufkette kein Wiederholungscode befindet, der in kurzer Folge zu wiederholten Anfragen führt.

Ordnungsgemäße Verwendung von Google APIs

Schlecht konzipierte API-Clients können sowohl das Internet als auch die Google-Server stärker als nötig belasten. Dieser Abschnitt enthält einige Best Practices für APIs-Kunden. Mithilfe dieser Best Practices können Sie verhindern, dass Ihre Anwendung aufgrund eines unbeabsichtigten Missbrauchs der APIs blockiert wird.

Synchronisierte Anfragen

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

Angenommen, eine Anwendung zeigt die Zeit in der aktuellen Zeitzone an. Diese Anwendung wird wahrscheinlich einen Alarm im Client-Betriebssystem einstellen, der ihn zu Beginn der Minute aktiviert, damit die angezeigte Zeit aktualisiert werden kann. Die Anwendung sollte im Rahmen der Verarbeitung für diesen Alarm keine API-Aufrufe ausführen.

API-Aufrufe als Reaktion auf einen festgelegten Alarm sind nicht gut, da die API-Aufrufe dann mit dem 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, erzeugt zu Beginn jeder Minute eine Traffic-Spitze mit einem 60-fachen Normalniveau.

Stattdessen könnte ein zweiter Alarm auf eine zufällig gewählte Zeit 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 die Anzeige aktualisiert wird.

Abgesehen vom Beginn der Minute sind andere häufige Synchronisierungszeiten, die Sie nicht berücksichtigen sollten, der Beginn einer Stunde und der Beginn eines jeden Tages um Mitternacht.