In diesem Dokument werden einige Techniken beschrieben, mit denen Sie die Leistung Ihrer Anwendung verbessern können. In einigen Fällen werden Beispiele aus anderen APIs oder generischen APIs verwendet, um die vorgestellten Ideen zu erläutern. Dieselben Konzepte gelten jedoch auch für die Google Drive API.
Komprimierung mit gzip
Durch Aktivierung der gzip-Komprimierung kann die für jede Anfrage benötigte Bandbreite einfach und bequem reduziert werden. Auch wenn die Dekomprimierung der Ergebnisse zusätzliche CPU-Zeit kostet, lohnt sie sich verglichen mit den Netzwerkkosten durchaus.
Sie müssen zwei Schritte ausführen, um eine mit gzip codierte Antwort zu erhalten: Legen Sie einen Header Accept-Encoding fest und ändern Sie den User-Agent so, dass er den String gzip enthält. Hier ein Beispiel für HTTP-Header im korrekten Format zur Aktivierung der gzip-Komprimierung:
Accept-Encoding: gzip User-Agent: my program (gzip)
Mit Teilressourcen arbeiten
Eine andere Möglichkeit zur Verbesserung der Leistung der API-Aufrufe besteht darin, nur den Teil der Daten zu senden und zu empfangen, der für Sie interessant ist. Dadurch lassen sich in der Anwendung die Übertragung, Analyse und Speicherung nicht benötigter Felder vermeiden und so Ressourcen wie Netzwerke, CPU und Speicher effizienter nutzen.
Es gibt zwei Arten von Teilanfragen:
- Teilantwort: Eine Anfrage, mit der Sie angeben, welche Felder in der Antwort enthalten sein sollen. Verwenden Sie dazu den Anfrageparameter
fields. - Patch: Eine Aktualisierungsanfrage, bei der Sie nur die zu ändernden Felder senden. Verwenden Sie dazu das HTTP-Verb
PATCH.
In den folgenden Abschnitten finden Sie weitere Informationen zu Teilanfragen.
Teilantwort
Standardmäßig wird vom Server nach der Verarbeitung einer Anfrage die komplette Darstellung einer Ressource zurückgeliefert. Sie können den Server zwecks Leistungsverbesserung aber auch anweisen, nur die Felder zu senden, die Sie wirklich benötigen, und erhalten dann eine Teilantwort.
Verwenden Sie zum Anfragen einer Teilantwort den Anfrageparameter fields, um anzugeben, welche Felder zurückgegeben werden sollen. Sie können diesen Parameter mit jeder beliebigen Anfrage verwenden, die Antwortdaten zurückgibt.
Beachten Sie, dass sich der fields-Parameter nur auf die Antwortdaten auswirkt. Er wirkt sich nicht auf die Daten aus, die Sie (gegebenenfalls) senden müssen. Verwenden Sie eine Patch-Anfrage, um die Datenmenge zu reduzieren, die bei der Änderung von Ressourcen gesendet wird.
Beispiel
Patch (Teilaktualisierung)
Sie können auch das Senden von unnötigen Daten vermeiden, wenn Sie Ressourcen ändern. Um nur aktualisierte Daten für die Felder zu senden, die Sie ändern, verwenden Sie das HTTP-Verb PATCH. Die Patch-Semantik, die in diesem Dokument beschrieben wird, ist anders (und einfacher) als die der älteren GData-Implementierung einer Teilaktualisierung.
Das kurze Beispiel unten zeigt, wie mit einer Patch-Anfrage die Datenmenge minimiert wird, die Sie zur Durchführung eines kleinen Updates benötigen.
Beispiel
Umgang mit der Antwort auf ein Patch
Nachdem eine gültige Patch-Anfrage verarbeitet wurde, gibt die API einen HTTP-Antwortcode 200 OK zusammen mit der vollständigen Darstellung der geänderten Ressource zurück. Wenn ETags von der API verwendet werden, aktualisiert der Server ETag-Werte, sobald eine Patch-Anfrage erfolgreich verarbeitet wird, wie bei PUT.
Die Patch-Anfrage gibt die vollständige Ressourcendarstellung zurück, es sei denn, Sie verwenden den fields-Parameter, um die zurückgegebene Datenmenge zu reduzieren.
Wenn eine Patch-Anfrage zu einem neuen Ressourcenstatus führt, der syntaktisch oder semantisch ungültig ist, gibt der Server einen HTTP-Statuscode 400 Bad Request oder 422 Unprocessable Entity zurück und der Ressourcenstatus bleibt unverändert. Beispiel: Wenn Sie versuchen, den Wert für ein Pflichtfeld zu löschen, gibt der Server einen Fehler zurück.
Alternative Schreibweise, wenn das PATCH-HTTP-Verb nicht unterstützt wird
Wenn Ihre Firewall keine HTTP-PATCH-Anfragen unterstützt, führen Sie eine HTTP-POST-Anfrage aus und setzen Sie den Override-Header auf PATCH (wie unten dargestellt):
POST https://www.googleapis.com/... X-HTTP-Method-Override: PATCH ...
Unterschied zwischen Patch und Aktualisierung
Wenn Sie in der Praxis Daten für eine Aktualisierungsanfrage senden, die das HTTP-Verb PUT verwendet, müssen Sie nur die Felder senden, die erforderlich oder optional sind. Wenn Sie Werte für Felder senden, die vom Server festgelegt werden, werden diese ignoriert. Obwohl dies wie eine andere Möglichkeit für eine Teilaktualisierung aussieht, hat dieser Ansatz einige Einschränkungen. Mit Aktualisierungen, die das HTTP-Verb PUT verwenden, schlägt die Anfrage fehl, wenn Sie erforderliche Parameter nicht angeben. Vorher festgelegte Daten werden gelöscht, wenn Sie keine optionalen Parameter angeben.
Aus diesem Grund ist die Verwendung eines Patch wesentlich sicherer. Sie geben nur Daten für die Felder an, die Sie ändern möchten; Felder, die Sie weglassen, werden nicht gelöscht. Sich wiederholende Elemente oder Arrays sind die einzige Ausnahme zu dieser Regel. Wenn Sie diese alle weglassen, bleiben sie unverändert. Wenn Sie ein Element oder Array angeben, wird das ganze Set durch das Set ersetzt, das Sie angeben.
Batchanfragen
In diesem Dokument erfahren Sie, wie API-Aufrufe in einem Batch zusammengefasst werden, um die Anzahl von HTTP-Verbindungen für den Client zu reduzieren.
In diesem Dokument wird ausschließlich das Erstellen einer Batchanfrage durch Senden einer HTTP-Anfrage behandelt. Wenn Sie stattdessen eine Google-Clientbibliothek für die Batchanfrage verwenden, lesen Sie die Informationen in der Dokumentation der Clientbibliothek.
Übersicht
Jede HTTP-Verbindung, die der Client erstellt, führt zu einem bestimmten Overhead. Die Google Drive API unterstützt Batchanfragen, damit der Client mehrere API-Aufrufe in einer einzelnen HTTP-Anfrage zusammenfassen kann.
Fallbeispiele für den Einsatz von Batchanfragen:
- Abrufen von Metadaten für eine große Anzahl von Dateien
- Metadaten oder Properties im Bulk-Verfahren aktualisieren
- Berechtigungen für eine große Anzahl von Dateien ändern, z. B. einen neuen Nutzer oder eine neue Gruppe hinzufügen
- Synchronisierung lokaler Clientdaten zum ersten Mal oder nach einer längeren Offlinezeit
In jedem Fall können Sie, anstatt jeden Aufruf einzeln zu senden, mehrere Aufrufe in einer einzigen HTTP-Anfrage zusammenfassen. Alle internen Anfragen müssen an dieselbe Google API gesendet werden.
Jede Batchanfrage ist auf maximal 100 Aufrufe begrenzt. Falls Sie eine größere Anzahl an Aufrufen benötigen, verwenden Sie mehrere Batchanfragen.
Hinweis: Die Batchverarbeitung der Google Drive API verwendet dieselbe Syntax wie die Batchverarbeitung von OData, jedoch mit einer anderen Semantik.
Weitere Einschränkungen:
- Batchanfragen mit mehr als 100 Aufrufen können zu einem Fehler führen.
- Die URL für jede innere Anfrage darf maximal 8.000 Zeichen lang sein.
- In Google Drive werden keine Batch-Vorgänge für Medien unterstützt, weder für den Upload noch für den Download oder den Export von Dateien.
Batchdetails
Eine Batchanfrage besteht aus mehreren, in einer HTTP-Anfrage zusammengefassten API-Aufrufen. Sie kann an den im Discovery-Dokument der API angegebenen batchPath gesendet werden. Der Standardpfad ist /batch/api_name/api_version. In diesem Abschnitt wird die Batchsyntax im Detail beschrieben. Anschließend finden Sie ein Beispiel.
Hinweis: Wenn n Anfragen zu einem Batch zusammengefasst sind, werden auch n Anfragen auf Ihr Nutzungskontingent angerechnet, nicht nur eine einzige Anfrage. Die Batchanfrage wird vor der Verarbeitung in eine Reihe von Anfragen aufgeteilt.
Format einer Batchanfrage
Eine Batchanfrage ist eine einzelne Standard-HTTP-Anfrage, die mehrere Google Drive API-Aufrufe enthält. Dabei wird der Inhaltstyp multipart/mixed verwendet. Jeder Teil der HTTP-Hauptanfrage enthält eine verschachtelte HTTP-Anfrage.
Jeder Teil beginnt mit seinem eigenen HTTP-Header Content-Type: application/http. Er kann auch einen optionalen Content-ID-Header haben. Die Header der einzelnen Teile sollen jedoch nur den Anfang des Teils markieren. Sie sind von der verschachtelten Anfrage getrennt. Nachdem der Server die Batchanfrage in separate Anfragen aufgeteilt hat, werden die Header der einzelnen Teile ignoriert.
Der Text jedes Teils ist an sich eine vollständige HTTP-Anfrage mit eigenem Verb, eigener URL, eigenen Headern und eigenem Text. Die HTTP-Anfrage darf nur den Pfadteil der URL enthalten; vollständige URLs sind in Batchanfragen nicht zulässig.
Die HTTP-Header für die äußere Batchanfrage gelten für jede Anfrage in dem Batch, ausgenommen Content--Header wie Content-Type. Wenn Sie einen bestimmten HTTP-Header sowohl in der äußeren Anfrage als auch in einem individuellen Aufruf verwenden, überschreibt der Wert des individuellen Aufrufheaders den Wert des Headers der äußeren Stapelanfrage. Die Header für einen individuellen Aufruf gelten nur für diesen Aufruf.
Beispiel: Wenn Sie einen Autorisierungsheader für einen bestimmten Aufruf angeben, gilt dieser Header nur für diesen Aufruf. Wenn Sie einen Autorisierungsheader für die äußere Anfrage angeben, gilt dieser Header für alle einzelnen Aufrufe, es sei denn, diese überschreiben ihn mit eigenen Autorisierungsheadern.
Wenn der Server die Stapelanfrage empfängt, wendet er (nach Bedarf) die Abfrageparameter und Header der äußeren Anfrage für jeden Teil an, und behandelt jeden Teil dann so, als wäre er eine separate HTTP-Anfrage.
Antwort auf eine Batchanfrage
Die Antwort des Servers ist eine einzelne Standard-HTTP-Antwort mit einem Inhaltstyp multipart/mixed. Jeder Teil ist die Antwort auf eine der Anfragen in der Batchanfrage in derselben Reihenfolge wie die einzelnen Anfragen.
Wie die Teile in der Anfrage enthält jeder Antwortteil eine vollständige HTTP-Antwort, einschließlich Statuscode, Headern und Text. Wie auch bei den Teilen in der Anfrage ist jedem Antwortteil ein Content-Type-Header vorangestellt, der den Beginn des Teils markiert.
Wenn ein bestimmter Teil einer Anfrage einen Content-ID-Header enthielt, enthält der entsprechende Teil der Antwort einen übereinstimmenden Content-ID-Header, wobei dem ursprünglichen Wert der String response- vorangestellt ist, wie im folgenden Beispiel dargestellt.
Hinweis: Der Server kann die Aufrufe in beliebiger Reihenfolge ausführen. Die Aufrufe werden nicht unbedingt in der Reihenfolge ausgeführt, in der Sie sie angegeben haben. Wenn Sie sicherstellen möchten, dass zwei Aufrufe in einer bestimmten Reihenfolge ausgeführt werden, können Sie sie nicht in einer einzelnen Anfrage senden. Senden Sie stattdessen den ersten Aufruf für sich alleine und warten Sie auf die Antwort auf den ersten Aufruf, bevor Sie den zweiten Aufruf senden.
Beispiel
Das folgende Beispiel zeigt die Verwendung der Batchverarbeitung mit der Google Drive API.
Beispiel-Batchanfrage
POST https://www.googleapis.com/batch/drive/v3 Accept-Encoding: gzip User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip) Content-Type: multipart/mixed; boundary=END_OF_PART Content-Length: 963--END_OF_PART Content-Length: 337 Content-Type: application/http content-id: 1 content-transfer-encoding: binary
POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id Authorization: Bearer authorization_token Content-Length: 70 Content-Type: application/json; charset=UTF-8
{ "emailAddress":"example@appsrocks.com", "role":"writer", "type":"user" } --END_OF_PART Content-Length: 353 Content-Type: application/http content-id: 2 content-transfer-encoding: binary
POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false Authorization: Bearer authorization_token Content-Length: 58 Content-Type: application/json; charset=UTF-8
{ "domain":"appsrocks.com", "role":"reader", "type":"domain" } --END_OF_PART--
Beispiel für eine Stapelantwort
Dies ist die Antwort auf die Beispielanfrage im vorherigen Abschnitt.
HTTP/1.1 200 OK Alt-Svc: quic=":443"; p="1"; ma=604800 Server: GSE Alternate-Protocol: 443:quic,p=1 X-Frame-Options: SAMEORIGIN Content-Encoding: gzip X-XSS-Protection: 1; mode=block Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk Transfer-Encoding: chunked X-Content-Type-Options: nosniff Date: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Vary: X-Origin Vary: Origin Expires: Fri, 13 Nov 2015 19:28:59 GMT--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-1
HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35
{ "id": "12218244892818058021i" }
--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-2
HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35
{ "id": "04109509152946699072k" }
--batch_6VIxXCQbJoQ_AATxy_GgFUk--
Bestimmte Felder aus der Anfrage zurückgeben
Wenn Sie den Parameter fields nicht angeben, gibt der Server eine Standardmenge von Feldern zurück, die für die Methode spezifisch sind. Die Methode files.list gibt beispielsweise nur die Felder kind, id, name und mimeType zurück.
Die zurückgegebenen Standardfelder entsprechen möglicherweise nicht Ihren Anforderungen. Wenn Sie angeben möchten, welche Felder in der Antwort zurückgegeben werden sollen, verwenden Sie den Systemparameter fields.
Weitere Informationen finden Sie unter Bestimmte Felder zurückgeben.
Für alle Methoden der Ressourcen about, comments (außer delete) und replies (außer delete) muss der Parameter fields festgelegt werden. Bei diesen Methoden wird kein Standardsatz von Feldern zurückgegeben.