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. Gehen Sie wie folgt vor, gilt für alle Anwendungstypen:
- So bereiten Sie sich auf den Autorisierungsprozess vor:
- Registrieren Sie Ihre Anwendung über die Google API Console.
- Aktivieren Sie die Photos APIs und rufen Sie OAuth-Details ab, z. B. Client-ID und einen Clientschlüssel. Weitere Informationen finden Sie unter Einstieg.
- Um auf Nutzerdaten zuzugreifen, sendet die Anwendung eine Anfrage an Google, um einen bestimmten Zugriffsbereich zu erhalten.
- Dem Nutzer wird von Google ein Zustimmungsbildschirm angezeigt, auf dem er gebeten wird, die Anwendung dazu zu autorisieren, einige seiner Daten abzufragen.
- Wenn der Nutzer zustimmt, stellt Google der Anwendung ein Zugriffstoken zur Verfügung, das nach kurzer Zeit abläuft.
- Die Anwendung fordert die Nutzerdaten an und hängt das Zugriffstoken an. zur Anfrage hinzufügen.
- Stellt Google fest, dass die Anfrage und das Token gültig sind, werden die angeforderten Daten zurückgegeben.
Informationen zum Bestimmen, welche Bereiche für Ihre Anwendung geeignet sind, finden Sie unter Autorisierung Bereiche.
Bei einigen Anwendungstypen sind zusätzliche Schritte erforderlich, wie z. B. Aktualisierungstokens, um neue Zugriffstokens zu erhalten. Detaillierte Informationen über siehe OAuth 2.0 für den Zugriff auf Google verwenden APIs
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 (unterliegt der Datenschutzerklärung Ihrer Anwendung). Mediaelement-IDs und Album-IDs verwenden um zugängliche URLs und Daten mithilfe der entsprechenden Endpunkte erneut abzurufen. Weitere Informationen findest du unter Medienelement abrufen oder Alben auflisten.
Wenn viele Medienelemente aktualisiert werden müssen, ist es möglicherweise effizienter, das Element Suchparameter, die die Medienelemente zurückgegeben haben, und senden die Abfrage erneut, um sie neu zu laden. Daten.
SSL-Zugriff
HTTPS ist für alle Webdienstanfragen der Photos APIs erforderlich, die den folgende URL:
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 minimale Verspätung sollte 1 s betragen
sofern nicht anders angegeben.
Bei 429-Fehlern kann der Client den Vorgang mit einer minimalen Verzögerung von 30s wiederholen. Für alle anderen
Fehler, ist „Wiederholen“ möglicherweise nicht 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 bei der Verarbeitung Ihrer Anfrage ein Fehler auftreten.Möglicherweise erhalten Sie
4XX oder 5XX HTTP-Antwortcode, oder die TCP-Verbindung schlägt irgendwo fehl
zwischen Ihrem Client und dem Google-Server. Oft lohnt es sich, die Anfrage noch einmal zu senden. Die Folgeanfrage kann erfolgreich sein, wenn die ursprüngliche Anfrage fehlgeschlagen ist. Sie können jedoch
Es ist wichtig, keine wiederholten
Anfragen an die Server von Google in einer Schleife auszuführen. Dieses Looping-Verhalten kann das Netzwerk zwischen Ihrem Client 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 multiplikativen Faktor erhöht, ein Ansatz, bekannt als Exponentiell Backoff.
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 der APIs. Wenn Sie diese Best Practices befolgen, können Sie verhindern, 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, eine Anwendung zeigt die Zeit in der aktuellen Uhrzeit an. . Diese App löst wahrscheinlich einen Alarm im Betriebssystem des Clients aus und es zu Beginn der Minute geweckt wird, damit die angezeigte Zeit aktualisiert. 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, sendet die Anwendung Aufrufe an alle APIs, die er benötigt, und die Ergebnisse speichert. Um die Anzeige zu Beginn des Minute verwendet die Anwendung zuvor gespeicherte Ergebnisse, anstatt den API noch einmal ein. 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.