Améliorer les performances

Compression avec gzip

La compression gzip est un moyen pratique et facile de réduire la bande passante requise pour chaque requête. Même si la décompression des résultats nécessite un temps CPU supplémentaire, la compression est généralement très avantageuse en termes de coûts de réseau.

Pour pouvoir recevoir une réponse encodée au format gzip, vous devez effectuer deux opérations : définir un en-tête Accept-Encoding et modifier votre user-agent afin d'y inclure la chaîne gzip. Voici un exemple d'en-têtes HTTP syntaxiquement corrects pour l'activation de la compression gzip :

Accept-Encoding: gzip
User-Agent: my program (gzip)

Utiliser une partie des ressources

Un autre moyen d'améliorer les performances de vos appels d'API consiste à n'envoyer et recevoir que la partie des données qui vous intéresse. Ainsi, vous évitez à votre application le transfert, l'analyse et le stockage de champs inutiles. En outre, cela permet une utilisation plus efficace des ressources, y compris le réseau, l'unité centrale et la mémoire.

Il existe deux types de requêtes partielles :

• Réponse partielle : requête dans laquelle vous spécifiez les champs à inclure dans la réponse (utilisez le paramètre de requête fields).
• Mise à jour partielle ("patch") : requête de mise à jour dans laquelle vous n'envoyez que les champs à modifier (utilisez le verbe HTTP PATCH).

Vous trouverez plus d'informations sur les requêtes partielles dans les sections suivantes.

Réponse partielle

Par défaut, le serveur renvoie la représentation complète d'une ressource après avoir traité les requêtes. Pour de meilleures performances, vous pouvez demander au serveur de n'envoyer que les champs dont vous avez vraiment besoin afin d'obtenir une réponse partielle.

Pour demander une réponse partielle, utilisez le paramètre de requête fields afin de spécifier les champs qui vous intéressent. Vous pouvez définir ce paramètre pour toute requête qui affiche des données de réponse.

Notez que le paramètre fields n'affecte que les données de réponse. Il n'a aucune incidence sur les éventuelles données à envoyer. Pour réduire le volume de données que vous envoyez lors de la modification des ressources, utilisez une requête patch.

Exemple

"Patch" (mise à jour partielle)

Vous pouvez aussi éviter l'envoi de données inutiles lors de la modification des ressources. Pour n'envoyer que les données mises à jour des champs auxquels vous apportez des modifications, utilisez le verbe HTTP PATCH. La sémantique "patch" décrite dans ce document est différente de l'ancienne mise en œuvre GData de la mise à jour partielle, et elle est plus simple.

Le court exemple ci-dessous illustre la manière dont l'utilisation de "patch" réduit au minimum les données à envoyer pour effectuer une petite mise à jour.

Exemple

Traitement de la réponse à une requête "patch"

Une fois que l'API a traité une requête "patch" correctement formulée, elle renvoie un code de réponse HTTP 200 OK ainsi que la représentation complète de la ressource modifiée. Si l'API utilise des ETag, le serveur met à jour les valeurs ETag lorsqu'il réussit à traiter une requête "patch", tout comme il le fait avec PUT.

La requête "patch" renvoie la représentation complète de la ressource, sauf si vous définissez le paramètre fields de manière à réduire le volume de données renvoyées.

Si une requête "patch" entraîne un nouvel état de ressource incorrect au niveau syntaxique ou sémantique, le serveur renvoie un code d'état HTTP 400 Bad Request ou 422 Unprocessable Entity, et l'état de la ressource n'est pas modifié. Par exemple, si vous tentez de supprimer la valeur d'un champ obligatoire, le serveur renvoie une erreur.

Autre notation syntaxique lorsque le verbe HTTP "PATCH" n'est pas accepté

Si votre pare-feu n'autorise pas les requêtes HTTP PATCH, créez une requête HTTP POST, puis définissez l'en-tête de remplacement sur PATCH, comme indiqué ci-dessous :

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

Différence entre "patch" et "update"

En pratique, lorsque vous envoyez des données pour une requête "update" utilisant le verbe HTTP PUT, vous ne devez envoyer que les champs obligatoires ou facultatifs. Si vous envoyez des valeurs de champs définis par le serveur, elles sont ignorées. Bien qu'elle puisse être perçue comme un autre moyen d'effectuer une mise à jour partielle, cette approche comporte certaines contraintes. Lorsque des mises à jour utilisent le verbe HTTP PUT, la requête échoue si vous ne fournissez pas les paramètres obligatoires. De plus, les données précédemment définies sont supprimées si vous ne fournissez pas les paramètres facultatifs.

C'est pourquoi il est plus prudent d'utiliser la requête "patch" : vous ne fournissez que les données des champs à modifier, et les champs que vous omettez ne sont pas supprimés. La seule exception à cette règle concerne les éléments ou tableaux répétitifs. Si vous les omettez tous, ils ne sont pas modifiés, mais si vous en fournissez un, ils sont tous remplacés par l'ensemble fourni.

Présentation

Chaque connexion HTTP effectuée par votre client entraîne certains coûts. L'API Google Drive accepte les requêtes par lot, ce qui permet à votre client d'intégrer plusieurs appels d'API dans une seule requête HTTP.

Voici quelques exemples de situations dans lesquelles l'utilisation de requêtes par lot peut s'avérer utile :

• Récupérer les métadonnées d'un grand nombre de fichiers
• Mettre à jour des métadonnées ou des propriétés de façon groupée
• Modification des autorisations pour un grand nombre de fichiers, par exemple en ajoutant un utilisateur ou un groupe.
• Synchronisation des données client locales pour la première fois ou après une longue période hors connexion

Dans chacun de ces cas, vous pouvez regrouper plusieurs appels en une seule requête HTTP plutôt que de les envoyer séparément. Toutes les requêtes internes doivent être transmises à la même API Google.

Une même requête par lot peut contenir jusqu'à 100 appels. Si vous devez effectuer plus d'appels, utilisez plusieurs requêtes par lot.

Remarque: Le système de requêtes par lot de l'API Google Drive utilise la même syntaxe que le système de traitement par lot OData, mais la sémantique diffère.

Voici d'autres contraintes:

• Les requêtes par lot comportant plus de 100 appels peuvent entraîner une erreur.
• La longueur de l'URL de chaque requête interne est limitée à 8 000 caractères.
• Google Drive n'est pas compatible avec les opérations par lot pour les éléments multimédias, que ce soit pour l'importation ou le téléchargement, ou pour l'exportation de fichiers.

Informations sur les lots

Une requête par lot est constituée de plusieurs appels d'API combinés en une seule requête HTTP, qui peut être envoyée au chemin batchPath spécifié dans le document de découverte des API. Le chemin par défaut est /batch/api_name/api_version. Cette section décrit la syntaxe des requêtes par lot plus en détail. Vous en trouverez un exemple plus bas.

Remarque : Un ensemble de n requêtes regroupées est comptabilisé comme n requêtes dans votre limite d'utilisation, et non comme une seule. Avant d'être traitée, la requête par lot est décomposée en un ensemble de requêtes.

Format d'une requête par lot

Une requête par lot est une requête HTTP standard unique qui comprend plusieurs appels d'API Google Drive et utilise le type de contenu multipart/mixed. Chacune des parties de cette requête HTTP principale contient une requête HTTP imbriquée.

Chaque partie commence par son en-tête HTTP Content-Type: application/http, mais peut également comporter un en-tête Content-ID facultatif. Les en-têtes des différentes parties ne servent toutefois qu'à signaler le début des parties et sont séparés de la requête imbriquée. Une fois que le serveur a décomposé la requête par lot en requêtes distinctes, les en-têtes de parties sont ignorés.

Le corps de chaque partie est lui-même composé d'une requête HTTP complète dotée de son propre verbe, de son URL, de ses en-têtes et de son corps. Comme les requêtes par lot n'acceptent pas les URL complètes, la requête HTTP ne doit contenir que le chemin de l'URL.

Les en-têtes HTTP des requêtes par lot externes s'appliquent à toutes les requêtes au sein du lot, à l'exception des en-têtes Content- tels que Content-Type. Si vous spécifiez un en-tête HTTP spécifique à la fois dans la requête externe et dans un appel individuel, la valeur de l'en-tête de l'appel individuel remplace alors celle de la requête par lot externe. Les en-têtes d'un appel individuel ne s'appliquent qu'à cet appel.

Par exemple, si vous fournissez un en-tête "Authorization" à un appel spécifique, l'en-tête ne s'applique qu'à cet appel. Mais si vous fournissez un en-tête "Authorization" à la requête externe, il s'applique à tous les appels individuels, sauf s'ils le remplacent par leurs propres en-têtes "Authorization".

Lorsque le serveur reçoit la requête par lot, il applique les paramètres de requête et les en-têtes (selon le cas) de la requête externe à chaque partie, puis traite ces parties comme s'il s'agissait de requêtes HTTP distinctes.

Réponse à une requête par lot

La réponse du serveur est une réponse HTTP standard unique avec un type de contenu multipart/mixed. Chaque partie constitue la réponse à l'une des requêtes de la requête par lot et apparaît dans le même ordre que celles-ci.

À l'instar des parties de la requête, les parties de la réponse contiennent chacune une réponse HTTP complète, qui comprend un code d'état, des en-têtes et un corps. Elles sont aussi précédées d'un en-tête Content-Type signalant le début de la partie.

Si une partie donnée de la requête possède un en-tête Content-ID, la partie correspondante de la réponse dispose alors du même en-tête Content-ID, avec une valeur initiale précédée de la chaîne response-, comme le montre l'exemple suivant.

Remarque : Le serveur peut effectuer vos appels dans n'importe quel ordre. Ne vous attendez pas à ce qu'ils soient exécutés selon l'ordre dans lequel vous les avez spécifiés. Si vous souhaitez que deux appels se produisent dans un ordre donné, évitez de les envoyer dans la même requête. Vous devez plutôt envoyer le premier appel seul, attendre la réponse, puis envoyer le second.

Exemple

L'exemple suivant montre comment utiliser les requêtes par lot avec l'API Google Drive.

Exemple de requête par lot

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

Exemple de réponse par lot

Il s'agit de la réponse à l'exemple de requête abordé dans la section précédente.

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