Cette page a été traduite par l'API Cloud Translation.

Améliorer les performances

Ce document présente quelques techniques que vous pouvez utiliser pour améliorer les performances de votre application. Dans certains cas, des exemples d'autres API ou d'API génériques permettent d'illustrer les idées exposées. Toutefois, les mêmes concepts s'appliquent à l'API Google Drive.

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

L'exemple suivant illustre l'utilisation du paramètre fields avec une API générique (fictive) nommée "demo".

Requête simple : cette requête HTTP GET omet le paramètre fields et renvoie la ressource complète.

https://www.googleapis.com/demo/v1

Réponse complète : les données de la ressource complète incluent les champs suivants, en plus de plusieurs autres champs qui ont été omis pour des raisons de concision.

{
  "kind": "demo",
  ...
  "items": [
  {
    "title": "First title",
    "comment": "First comment.",
    "characteristics": {
      "length": "short",
      "accuracy": "high",
      "followers": ["Jo", "Will"],
    },
    "status": "active",
    ...
  },
  {
    "title": "Second title",
    "comment": "Second comment.",
    "characteristics": {
      "length": "long",
      "accuracy": "medium"
      "followers": [ ],
    },
    "status": "pending",
    ...
  },
  ...
  ]
}

Requête de réponse partielle : la requête suivante portant sur cette même ressource utilise le paramètre fields afin de réduire de manière significative le volume de données renvoyées.

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

Réponse partielle : suite à la requête ci-dessus, le serveur renvoie une réponse qui ne contient que les informations "kind" ainsi qu'un tableau d'éléments ("items") dépouillé, ne comprenant que les données de titre HTML et des caractéristiques de longueur dans chaque élément.

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

Notez que la réponse est un objet JSON, qui ne comprend que les champs sélectionnés et leurs objets parents englobants.

La syntaxe du paramètre fields et le détail des éléments renvoyés dans la réponse sont décrits ci-dessous.

Récapitulatif de la syntaxe du paramètre "fields"

Le format de la valeur du paramètre de requête fields repose globalement sur la syntaxe XPath. La syntaxe acceptée est résumée ci-dessous, et des exemples supplémentaires sont présentés dans la section suivante.

Incluez une liste dont les éléments sont séparés par une virgule pour sélectionner plusieurs champs.
Incluez a/b pour sélectionner un champ b imbriqué dans le champ a. Incluez a/b/c pour sélectionner un champ c imbriqué dans le champ b.

Exception : Pour les réponses de l'API qui utilisent des wrappers "data", lorsque la réponse est imbriquée dans un objet data de type data: { ... }, n'incluez pas data dans la spécification fields. L'ajout de l'objet de données à une spécification "fields" comme data/a/b génère une erreur. Utilisez plutôt une spécification fields simple comme a/b.
Incluez un sous-sélecteur pour demander un ensemble de sous-champs spécifiques de tableaux ou d'objets en plaçant des expressions entre parenthèses : "( )".
Par exemple, fields=items(id,author/email) ne renvoie que l'ID d'élément et l'adresse e-mail de l'auteur pour chaque élément du tableau. Vous pouvez aussi spécifier un sous-champ unique, où fields=items(id) équivaut à fields=items/id.
Si nécessaire, incluez des caractères génériques dans les sélections de champs.
Par exemple, fields=items/pagemap/* sélectionne tous les objets du champ "pagemap".

Autres exemples d'utilisation du paramètre "fields"

Les exemples ci-dessous décrivent l'impact de l'utilisation de la valeur de paramètre fields sur la réponse.

Remarque : Comme toutes les valeurs de paramètre de requête, la valeur du paramètre fields doit être encodée au format URL. Pour faciliter la lecture, les exemples de ce document omettent l'encodage.

Identifiez les champs devant être renvoyés ou effectuez des sélections de champs.

La valeur de paramètre de requête fields est une liste de champs séparés par une virgule, et chaque champ est spécifié en relation avec la racine de la réponse. Ainsi, lorsque vous exécutez une opération list, la réponse correspond à une collection et inclut généralement un tableau de ressources. Si vous exécutez une opération qui renvoie une ressource unique, les champs sont spécifiés par rapport à cette ressource. Si le champ que vous sélectionnez est un tableau (ou figure dans un tableau), le serveur renvoie la partie sélectionnée de tous les éléments du tableau.

Exemples pour les collections :

Exemples	Effet
`items`	Renvoie tous les éléments du tableau d'éléments, y compris tous les champs de chaque élément, mais aucun autre champ.
`etag,items`	Renvoie le champ `etag` ainsi que tous les éléments du tableau "items".
`items/title`	Ne renvoie que le champ `title` pour tous les éléments du tableau "items". Chaque fois qu'un champ imbriqué est renvoyé, la réponse inclut les objets parents qui le contiennent. Les champs parents n'incluent pas d'autres champs enfants, sauf si ceux-ci sont également sélectionnés de manière explicite.
`context/facets/label`	Ne renvoie que le champ `label` pour tous les membres du tableau `facets`, qui est lui-même imbriqué sous l'objet `context`.
`items/pagemap/*/title`	Pour chaque élément du tableau "items", ne renvoie que le champ `title` (s'il existe) de tous les objets qui sont des enfants de `pagemap`.

Exemples pour les ressources :

Exemples	Effet
`title`	Renvoie le champ `title` de la ressource demandée.
`author/uri`	Renvoie le sous-champ `uri` de l'objet `author` de la ressource demandée.
`links/*/href`	Renvoie le champ `href` de tous les objets enfants de `links`.

Ne demandez que des parties de champs spécifiques à l'aide de sous-sélections.

Par défaut, si votre requête spécifie des champs particuliers, le serveur renvoie les objets ou les éléments de tableau dans leur intégralité. Vous pouvez spécifier une réponse n'incluant que certains sous-champs. Pour ce faire, utilisez la syntaxe de sous-sélection ( ), conformément à l'exemple ci-dessous.

Exemple	Effet
`items(title,author/uri)`	Ne renvoie que la valeur `title` et la valeur `uri` de l'auteur pour chaque élément du tableau "items".

Traitement des réponses partielles

Après qu'un serveur a traité une demande correctement formulée incluant le paramètre de requête fields, il renvoie le code d'état HTTP 200 OK ainsi que les données demandées. Si le paramètre de requête fields comporte une erreur ou n'est pas correctement formulé pour une autre raison, le serveur renvoie le code d'état HTTP 400 Bad Request ainsi qu'un message d'erreur indiquant à l'utilisateur la raison pour laquelle sa sélection de champs est incorrecte (par exemple, "Invalid field selection a/b").

Voici l'exemple de réponse partielle mentionné dans l'introduction ci-dessus. La requête contient le paramètre fields de manière à spécifier les champs à renvoyer.

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

La réponse partielle se présente comme suit :

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

Remarque : Dans le cas des API qui acceptent des paramètres de requête pour la pagination des données (par exemple, maxResults et nextPageToken), utilisez ces paramètres afin que la taille des résultats de chaque requête soit gérable. Cela permet de garantir l'amélioration des performances possible grâce à la réponse partielle.

"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

Dans cet exemple, une simple requête "patch" permet de ne mettre à jour que le titre d'une ressource API "demo" générique (fictive). La ressource comporte également un commentaire, un ensemble de caractéristiques, un état et plusieurs autres champs, mais cette requête n'envoie que le champ title, puisqu'il s'agit du seul champ à modifier :

PATCH https://www.googleapis.com/demo/v1/324
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "title": "New title"
}

Réponse :

200 OK

{
  "title": "New title",
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "accuracy": "high",
    "followers": ["Jo", "Will"],
  },
  "status": "active",
  ...
}

Le serveur renvoie un code d'état 200 OK, ainsi que la représentation complète de la ressource mise à jour. Seule la valeur du champ title a été modifiée, puisqu'il s'agit du seul champ inclus dans la requête "patch".

Remarque : Vous pouvez améliorer l'efficacité de vos requêtes de mise à jour en combinant le paramètre de réponse partielle fields avec le verbe "patch". Une requête "patch" ne permet de réduire que la taille de la requête. Toutefois, en utilisant une réponse partielle, vous pouvez également réduire la taille de la réponse. La solution pour limiter le volume de données envoyées dans les deux sens consiste donc à exécuter une requête "patch" comportant le paramètre fields.

Sémantique d'une requête "patch"

Le corps de la requête "patch" ne comprend que les champs de la ressource à modifier. Lorsque vous spécifiez un champ, vous devez intégrer tous les objets parents englobants (ceux-ci étant renvoyés avec une réponse partielle). Les données modifiées que vous envoyez sont fusionnées avec les données de l'objet parent, le cas échéant.

Ajouter : pour ajouter un champ qui n'existe pas encore, spécifiez le nouveau champ et sa valeur.
Modifier : pour modifier la valeur d'un champ existant, spécifiez ce champ et définissez sa nouvelle valeur.
Supprimer : pour supprimer un champ, spécifiez ce champ et définissez-le sur null. Par exemple, "comment": null. Vous pouvez également supprimer un objet entier (s'il est modifiable) en le définissant sur null. Si vous utilisez la bibliothèque cliente des API Java, indiquez plutôt Data.NULL_STRING. Pour en savoir plus, consultez la section JSON null.

Remarque à propos des tableaux : Les requêtes "patch" contenant des tableaux remplacent le tableau existant par celui que vous fournissez. Il est impossible de modifier, d'ajouter ni de supprimer les éléments d'un tableau de manière fragmentaire.

Utilisation de la sémantique "patch" dans le cadre d'un cycle lecture-modification-écriture

Il peut être utile de commencer par obtenir une réponse partielle avec les données à modifier. Cette étape est particulièrement importante pour les ressources qui utilisent des ETag, car vous devez fournir la valeur ETag en cours d'utilisation dans l'en-tête HTTP If-Match afin que la mise à jour de la ressource soit effectuée correctement. Une fois que vous avez obtenu ces données, vous pouvez modifier les valeurs de votre choix et renvoyer la représentation partielle modifiée à l'aide d'une requête "patch". L'exemple qui suit suppose que la ressource "demo" utilise des ETag :

GET https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token

La réponse partielle se présente sous la forme suivante :

200 OK

{
  "etag": "ETagString"
  "title": "New title"
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "level": "5",
    "followers": ["Jo", "Will"],
  }
}

La requête "patch" suivante est basée sur cette réponse. Comme indiqué ci-dessous, cette requête "patch" utilise également le paramètre fields afin de limiter les données renvoyées dans la réponse :

PATCH https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json
If-Match: "ETagString"

{
  "etag": "ETagString"
  "title": "",                  /* Clear the value of the title by setting it to the empty string. */
  "comment": null,              /* Delete the comment by replacing its value with null. */
  "characteristics": {
    "length": "short",
    "level": "10",              /* Modify the level value. */
    "followers": ["Jo", "Liz"], /* Replace the followers array to delete Will and add Liz. */
    "accuracy": "high"          /* Add a new characteristic. */
  },
}

Le serveur renvoie un code d'état HTTP "200 OK", ainsi que la représentation partielle de la ressource mise à jour :

200 OK

{
  "etag": "newETagString"
  "title": "",                 /* Title is cleared; deleted comment field is missing. */
  "characteristics": {
    "length": "short",
    "level": "10",             /* Value is updated.*/
    "followers": ["Jo" "Liz"], /* New follower Liz is present; deleted Will is missing. */
    "accuracy": "high"         /* New characteristic is present. */
  }
}

Élaboration directe d'une requête "patch"

Dans certains cas, vous devez baser vos requêtes "patch" sur des données qu'il vous faut d'abord obtenir. Par exemple, si vous souhaitez ajouter un élément dans un tableau sans perdre aucun des éléments existants qu'il contient, vous devez d'abord obtenir ces données. De même, si une API utilise des ETag, vous devez joindre l'ancienne valeur ETag à votre requête pour effectuer la mise à jour de la ressource.

Remarque : Vous pouvez spécifier un en-tête HTTP "If-Match: *" pour forcer la mise à jour partielle lorsque des ETag sont utilisés. Dans ce cas, il n'est pas nécessaire de procéder à la lecture avant l'écriture.

Dans d'autres cas, vous pouvez cependant élaborer la requête "patch" directement, sans avoir à extraire d'abord les données existantes. Par exemple, vous pouvez facilement configurer une requête "patch" visant à mettre à jour la valeur d'un champ ou à en ajouter un. Voici un exemple :

PATCH https://www.googleapis.com/demo/v1/324?fields=comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "comment": "A new comment",
  "characteristics": {
    "volume": "loud",
    "accuracy": null
  }
}

Avec cette requête, si le champ "comment" possède déjà une valeur, celle-ci est remplacée par la nouvelle. Dans le cas contraire, il est défini sur la nouvelle valeur. De même, si une caractéristique de volume est présente, sa valeur est remplacée. Dans le cas contraire, elle est créée. S'il est défini, le champ "accuracy" est supprimé.

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.

Requêtes par lot

Ce document explique comment autoriser les appels d'API par lot pour réduire le nombre de connexions HTTP que votre client doit effectuer.

Vous allez plus spécifiquement apprendre à exécuter une requête par lot en envoyant une requête HTTP. Si vous souhaitez plutôt exécuter ce type de requête à l'aide d'une bibliothèque cliente Google, consultez la documentation associée à la bibliothèque en question.

Présentation

Chaque connexion HTTP effectuée par votre client entraîne certains coûts. L'API Google Drive est compatible avec le traitement 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 manière groupée
Modifier les autorisations pour un grand nombre de fichiers, comme l'ajout d'un utilisateur ou d'un groupe
Synchronisation des données client locales pour la première fois ou après une période d'inactivité prolongée.

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.

Vous êtes limité à 100 appels pour une même requête par lot. 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.

Autres contraintes:

Les requêtes par lot avec plus de 100 appels peuvent générer une erreur.
La longueur de l'URL est limitée à 8 000 caractères pour chaque requête interne.
Google Drive n'accepte pas les opérations par lot pour les contenus multimédias, que ce soit pour l'importation ou le téléchargement, ni 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 illustre l'utilisation du traitement 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--

Renvoyer des champs spécifiques de la requête

Par défaut, le serveur renvoie un ensemble par défaut de champs de ressources spécifiques à la méthode utilisée. Par exemple, La méthode files.list peut uniquement renvoyer la id, name et mimeType. Ces champs ne correspondent peut-être pas aux champs exacts que vous besoin. Si vous devez renvoyer d'autres champs, consultez Renvoyez des champs spécifiques pour un fichier.