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 sont applicables à l'API Compute Engine.

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.