Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Pourquoi nous comptons les requêtes groupées par élément et non par appel
Un endpoint par lot qui accepte mille adresses en un seul appel et ne compte que pour une requête sur votre quota paraît généreux sur une page de tarifs. Il ne l'est pas. C'est une erreur d'arrondi qui ne demande qu'à devenir un problème de capacité, car le travail réel derrière cet appel, mille recherches individuelles, n'a pas diminué simplement parce qu'il est arrivé dans une seule enveloppe.
Nous comptons les requêtes groupées et par lot comme tout le reste : un élément, une requête. Si vous envoyez mille adresses dans un seul appel par lot, cela représente mille requêtes sur votre franchise gratuite ou votre crédit prépayé, exactement comme si vous aviez appelé l'endpoint mille fois séparément. La commodité du traitement par lot, moins d'allers-retours, moins de surcharge de connexion, est réelle et mérite d'être exploitée. Le coût des recherches elles-mêmes ne change pas parce que vous les avez demandées ensemble.
Facturer les appels groupés à un prix artificiellement bas crée une étrange distorsion. Cela récompense le fait de restructurer votre intégration autour de gros appels groupés uniquement pour économiser, et non parce que le traitement par lots correspond réellement à votre flux de travail. Cela rend aussi la planification de capacité réelle d'un fournisseur plus difficile à évaluer de l'extérieur, puisqu'une « requête » ne désigne plus une unité de travail constante. Un client qui compare des fournisseurs sur le nombre de requêtes par jour ne peut pas comparer équitablement si la requête d'un fournisseur peut secrètement contenir mille recherches et celle d'un autre non.
Le décompte par élément garde aussi tout leur sens à nos en-têtes de quota. Chaque réponse indique ce que vous avez consommé et ce qu'il vous reste, et ce nombre n'a de sens que si une requête reste une requête, quelle que soit sa forme. Si un lot de mille éléments ne coûtait discrètement qu'une unité, ces en-têtes ne vous diraient presque rien de votre consommation réelle, et vous ne découvririez le vrai chiffre qu'au moment où un usage bien plus important, non groupé, atteindrait une limite à laquelle vous ne vous attendiez pas.
Il y a aussi un argument d'équité. Un client qui envoie des appels individuels et un client qui envoie des lots nous demandent d'effectuer la même quantité totale de travail pour le même prix total. Facturer moins cher chaque recherche au client qui envoie des lots, simplement parce que ses requêtes sont regroupées, reviendrait à faire subventionner par le client aux appels individuels une infrastructure qu'il ne sollicite pas. Facturer la même chose par recherche aux deux clients lie le prix au travail, et non à la façon dont ce travail est emballé.
Rien de tout cela ne rend le traitement par lots inutile. Il reste la bonne façon d'envoyer un grand ensemble connu de recherches en un seul aller-retour, et nous le prenons en charge parce que moins de connexions et moins de surcharge représentent un vrai gain d'efficacité de votre côté. Ce que le traitement par lots ne doit pas faire, d'un côté comme de l'autre de la requête, c'est modifier le coût réel des recherches. Mille recherches restent mille recherches, qu'elles arrivent une par une au fil d'un après-midi ou toutes ensemble dans un seul appel.