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.
Pour un versionnage d'API ennuyeux et stable
Un fournisseur qui annonce une nouvelle version majeure de son API annonce généralement, à chaque client disposant d'une intégration existante, un projet que celui-ci n'a pas demandé. Même un changement incompatible bien communiqué signifie que quelqu'un doit dégager du temps pour lire un guide de migration, mettre à jour le traitement des requêtes ou des réponses, le tester et le déployer, selon un calendrier fixé par la feuille de route du fournisseur plutôt que par quoi que ce soit qui se passe dans le produit de ce client.
Nous pensons que la stabilité d'une API mérite d'être traitée comme un objectif de conception à part entière, et non comme un manque de dynamisme. Une structure de réponse, une fois publiée, devrait continuer à signifier ce qu'elle signifiait lorsqu'un développeur a commencé à l'utiliser. De nouveaux champs peuvent être ajoutés de manière optionnelle, à la manière dont l'altitude, les menaces IP et le détail réseau sont des extras activables ajoutés aux réponses standard plutôt que des restructurations imposées. Ce qui ne devrait pas arriver en silence, c'est qu'un champ existant change de sens, qu'un code de statut soit réaffecté ou qu'une structure soit réorganisée sous le même numéro de version.
Si les changements incompatibles sont si fréquents dans ce secteur, c'est en partie parce qu'ils sont bon marché pour le fournisseur et coûteux pour le client, et que les deux parties négocient rarement ce déséquilibre directement. Livrer un modèle interne plus propre est une véritable réussite technique pour l'équipe d'un fournisseur. Cela devient un fardeau dès que cela oblige chaque intégration en aval à changer en conséquence, selon un calendrier que le fournisseur contrôle et que le client ne contrôle pas.
Cela ne veut pas dire qu'une API ne doit jamais changer. Cela veut dire que les changements doivent être additifs chaque fois que possible et que, lorsqu'un véritable changement incompatible est inévitable, il doit être assez rare pour qu'un client puisse être sûr que la structure sur laquelle il s'est appuyé fonctionnera encore des mois ou des années plus tard, sans devoir surveiller un journal des modifications pour s'en prémunir. La stabilité n'est pas l'immobilisme. C'est la promesse que le travail d'intégration d'aujourd'hui n'est pas assorti d'une date d'expiration dont personne ne vous a parlé.
Nous avons aussi une raison intéressée de défendre cette position, au-delà de la bonne volonté envers nos clients. Chaque hôte de compatibilité que nous exploitons repose sur la reproduction fidèle, dans la durée, de la structure d'un autre fournisseur, ce qui ne fonctionne que si les structures, une fois reproduites, sont des cibles suffisamment stables pour qu'on puisse s'y fier. Une entreprise qui traite sa propre API comme jetable, à repenser dès que cela l'arrange, est une entreprise dont les garanties de compatibilité ne sont pas vraiment des garanties non plus. La stabilité doit être une habitude qui s'applique partout, sinon elle ne s'applique vraiment nulle part.
Ennuyeux n'est pas une critique ici. Une version d'API qui fonctionne encore, des années plus tard, exactement comme lorsque vous l'avez intégrée ne prouve pas que rien ne s'est amélioré. Elle prouve que les améliorations ont été apportées d'une manière qui ne vous obligeait pas à les remarquer, ce qui est tout l'intérêt d'une bonne discipline de versionnage.