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.
Le coût discret de la dépendance à un fournisseur
Personne ne s'inscrit à une API en prévoyant d'en devenir captif. La dépendance n'arrive pas sous la forme d'une clause de contrat que l'on peut négocier. Elle s'accumule, une commodité après l'autre, jusqu'à ce que le coût du changement soit discrètement devenu plus élevé que celui du problème qui vous avait fait envisager de changer.
Cela commence modestement. Vous installez le SDK du fournisseur parce qu'il vous épargne quelques heures d'écriture manuelle d'appels HTTP. Vous stockez la structure de l'objet de réponse directement dans votre base de données au lieu de la faire correspondre à votre propre schéma, parce que cette correspondance semblait alors un travail inutile. Vous construisez la gestion des erreurs autour des codes de statut propres au fournisseur plutôt que d'un modèle général. Chacun de ces choix a du sens en soi, sur le moment, sous la pression normale des livraisons. Aucun n'est fait en pensant à la dépendance. Tous l'aggravent.
Des années plus tard, le fournisseur augmente ses prix, subit une panne en pleine période chargée, ou cesse simplement d'être la meilleure option pour une fonctionnalité dont vous avez désormais besoin. Changer devrait consister à choisir un nouveau fournisseur et à mettre à jour une valeur de configuration. Au lieu de cela, c'est un projet : réécrire la logique d'analyse éparpillée dans le code, reconstruire la gestion des erreurs, adapter tous les outils internes qui se sont développés autour de l'ancienne structure. Le coût du changement n'a jamais figuré sur une facture. Il a été payé d'avance, à travers de petites décisions d'intégration que personne n'avait signalées comme risquées à l'époque.
Nous avons conçu les hôtes de compatibilité précisément contre ce schéma. Si votre intégration utilise déjà la structure de requête et de réponse d'un autre fournisseur, la diriger vers l'un de nos 17 hôtes de compatibilité ne vous oblige pas à avoir anticipé la portabilité. Vous avez la possibilité de partir sans avoir eu la clairvoyance de vous y préparer. C'est une différence importante par rapport à la plupart des conseils contre la dépendance, qui recommandent généralement de « développer sur une couche d'abstraction dès le premier jour », un bon conseil que presque personne ne suit réellement sous la pression des délais.
L'authentification est un exemple plus modeste du même principe. Certains fournisseurs vous poussent vers une méthode d'authentification précise, ce qui lie votre intégration à un modèle client particulier. Nous acceptons une clé sous forme d'en-tête X-API-Key, d'en-tête Authorization Bearer, d'authentification HTTP Basic ou de paramètre de requête, sur chaque hôte, sans frais supplémentaires pour aucune de ces méthodes. Quel que soit le modèle que votre code existant utilise déjà pour d'autres API, le nôtre s'y adapte probablement, vous n'avez donc pas à réécrire votre couche d'authentification simplement pour nous essayer.
La raison honnête pour laquelle la dépendance persiste dans ce secteur, c'est qu'elle fonctionne commercialement. Un client qui partirait pour le seul prix reste souvent parce que partir implique une réécriture. Nous pensons que c'est un mauvais calcul sur lequel bâtir une entreprise, car il retient les clients déjà mécontents plutôt que ceux qui sont réellement satisfaits. Si partir reste peu coûteux, les clients qui restent le font parce que le produit en vaut toujours la peine, et non parce que la porte de sortie a été discrètement murée quelque part au cours de la deuxième année.