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 Android Over The Air.
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.