Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Définir des délais d'expiration adaptés aux traitements par lots à gros volume
Un délai d'expiration qui convient parfaitement à la recherche d'une seule adresse interrompra une requête en masse contenant quelques milliers d'éléments bien avant que le serveur ait fini de tous les traiter, ce qui ressemble à un échec alors que la requête aurait abouti avec suffisamment de temps.
Pourquoi les requêtes en masse demandent plus de temps
Chaque élément d'un tableau en masse est une recherche à part entière : une requête contenant 2 000 éléments représente donc environ 2 000 fois le traitement d'une recherche unique, même s'il ne s'agit que d'un seul appel HTTP de votre côté. Un délai d'une ou deux secondes, raisonnable pour une seule adresse, est loin de suffire pour une requête de cette taille.
Adapter le délai à la taille du lot
Réglez le délai d'expiration de votre client proportionnellement à la taille du tableau que vous envoyez, avec une marge pour les variations habituelles, plutôt que d'utiliser une valeur fixe unique pour toutes les requêtes de votre code, petites ou grandes.
timeout_seconds = max(5, item_count * 0.05)Il s'agit d'un point de départ à ajuster selon le comportement que vous observez, et non d'une valeur fixe faisant autorité, car le temps de traitement réel par élément n'est pas une garantie publiée.
Préférer des blocs plus petits à une requête géante
Plutôt que d'augmenter sans cesse les délais d'expiration pour absorber une requête unique toujours plus grosse, découpez un très gros travail en blocs de quelques centaines à quelques milliers d'éléments chacun. Des blocs plus petits nécessitent des délais plus courts et plus prévisibles, et un échec en cours de route ne vous coûte que le bloc en cours et non l'ensemble du travail.
Gérer un délai d'expiration dépassé
Si une requête expire de votre côté, vous ne savez pas forcément si le serveur a fini de la traiter ou non. Plutôt que de renvoyer aveuglément le même bloc, ce qui pourrait être décompté deux fois de votre quota si la requête d'origine a abouti, consultez les en-têtes de quota de votre dernier appel réussi pour estimer si le bloc expiré a probablement été traité, et renvoyez-le avec prudence.
Les délais d'expiration n'ont aucun effet sur le coût
Un délai d'expiration est un simple réglage côté client qui indique combien de temps vous acceptez d'attendre. Il n'a aucun effet sur le coût d'une requête, toujours une requête par élément traité, que votre client ait attendu jusqu'au bout ou abandonné plus tôt.
Adapter votre délai d'expiration à la taille de vos lots, et préférer plusieurs petits blocs à une très grosse requête, rend les gros travaux à la fois fiables et faciles à reprendre en cas de problème. Le découpage et la stratégie de quota pour les gros travaux sont détaillés dans la documentation sur les limites de débit.