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.
Les limites de débit doivent être documentées, pas découvertes
Il existe un type de mauvaise matinée bien particulier, qui commence par un pic de requêtes échouées et se termine avec un développeur qui lit pour la première fois la page d'état d'un fournisseur, en essayant de comprendre si les échecs viennent d'une panne ou d'une limite dont il ignorait l'existence. Cette matinée est entièrement évitable, et le fait qu'elle se produise encore dans ce secteur est un échec de documentation, pas d'infrastructure.
Une limite de débit n'est pas un secret. C'est une réalité opérationnelle d'un système, au même titre qu'une taille maximale de requête ou une méthode HTTP prise en charge, et sa place est la même : écrite noir sur blanc, avant que quiconque ne l'atteigne. Nous publions les nôtres dans la documentation des limites de débit, à côté des pages authentification et erreurs, afin que les chiffres dont un développeur a besoin pour planifier soient disponibles avant qu'il n'écrive la première ligne de code d'intégration, et non après un premier après-midi aux allures de panne.
La documentation seule ne suffit pas pour autant, car les limites peuvent dépendre de votre formule, et un document devient obsolète dès que le statut de votre compte change. C'est pourquoi chaque réponse comporte aussi des en-têtes de quota en temps réel : votre limite, ce que vous avez utilisé, le quota gratuit restant, la part du quota partagé de votre réseau déjà utilisée, votre crédit prépayé restant et le moment où le quota est réinitialisé. Vous n'avez pas à croiser un document avec votre tableau de bord pour savoir où vous en êtes. La réponse accompagne la réponse elle-même, à chaque appel.
Certains fournisseurs considèrent les limites publiées comme une faiblesse concurrentielle à cacher, en partant du principe qu'un chiffre visible incite les clients à le négocier à la baisse ou à le comparer à celui d'un concurrent. Nous pensons que ce réflexe est à l'envers. Une limite que personne ne peut voir ne protège pas mieux l'infrastructure du fournisseur. Cela signifie simplement que la première fois qu'un client découvre le vrai chiffre, c'est lorsqu'il l'a déjà dépassé, au pire moment possible pour un produit en croissance, devant ses propres utilisateurs.
Documenter les limites dès le départ impose aussi une discipline de conception au fournisseur. Si une limite de débit doit être publiée, il faut que ce soit un vrai chiffre que quelqu'un est prêt à assumer, et non un vague seuil interne ajusté discrètement dès qu'il devient gênant. Écrire le chiffre et le placer dans les en-têtes de réponse à chaque appel signifie que la limite doit réellement être la limite, de façon constante, ce qui est exactement la propriété dont un développeur a besoin.
Découvrir une limite de débit à cause d'une requête échouée en production n'est pas un rite de passage. C'est le signe que la documentation n'a pas fait son travail. La nôtre a pour but de faire de cette mauvaise matinée quelque chose que vous lisez à propos de quelqu'un d'autre, et non quelque chose qui vous arrive.