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 les hôtes compatibles comptent plus qu'un nouveau SDK
Chaque éditeur d'API veut que vous installiez son SDK. Un SDK crée de l'attachement. Dès que votre code importe une bibliothèque cliente, appelle ses méthodes et dépend de la forme de ses objets, changer de fournisseur signifie réécrire le code qui dialogue avec lui, et pas seulement changer une URL. Cet attachement est souvent le véritable modèle économique derrière un SDK gratuit et pratique, que quelqu'un le dise à voix haute ou non.
Nous avons choisi une autre approche. My Geocode dispose de 17 hôtes compatibles, chacun reproduisant la forme de requête et de réponse d'un autre fournisseur. Si votre code sait déjà appeler l'endpoint d'une API de géocodage connue et analyser son JSON, vous pouvez diriger exactement ce code vers notre hôte compatible et il continue de fonctionner. Aucun SDK à installer, aucune analyse de réponse à réécrire, aucun modèle d'objets propriétaire à apprendre.
Cela semble anodin jusqu'à ce que vous ayez réellement essayé de migrer un système de production hors d'une API. L'URL de l'endpoint est la partie facile. La partie difficile, ce sont tous les endroits de votre code qui accèdent à un nom de champ précis, gèrent une forme d'erreur précise ou supposent un style de pagination précis. Ces hypothèses se dispersent dans le code au fil des années, à des endroits que personne ne pense à vérifier. Un hôte compatible supprime le besoin de les trouver et de les corriger, car la forme ne change pas.
Un SDK, à l'inverse, résout un problème que vous ne rencontrerez qu'une fois, la première connexion à une API, au prix d'un problème que vous rencontrerez pendant toute la vie du produit : être lié aux choix de conception de ce SDK. Quand le SDK publie une modification incompatible, vous l'absorbez. Quand il cesse de maintenir une liaison pour un langage dont vous dépendez, vous l'absorbez aussi. Un simple hôte compatible HTTP n'a rien de tout cela. Ce n'est qu'une URL qui renvoie la forme de réponse que vous savez déjà lire.
Nous ne sommes pas contre les SDK en général. Une fine surcouche qui vous évite d'écrire du code HTTP répétitif est une commodité, pas un piège, tant que l'abandonner plus tard n'est pas un chantier aussi lourd que de changer de fournisseur. Le piège, c'est lorsque les formes du SDK deviennent les seules que votre code comprend, de sorte que partir signifie réécrire au lieu de reconfigurer.
Construire 17 hôtes compatibles nous a demandé plus de travail que construire un seul SDK. Chaque hôte doit reproduire fidèlement la forme de réponse d'un autre fournisseur, champ par champ, pour que les intégrations existantes ne voient pas la différence. Nous avons fait ce travail parce qu'il déplace le coût du changement de votre côté vers le nôtre. Vous pouvez vérifier si nos données, notre disponibilité et nos tarifs vous conviennent sans d'abord payer un coût d'intégration juste pour le savoir. Consultez la liste complète des hôtes compatibles ou la documentation pour voir comment chacun correspond à l'original.
Un nouveau SDK demande à un développeur de faire confiance aux choix techniques d'une entreprise pendant toute la durée d'un projet. Un hôte compatible demande beaucoup moins : changer une URL de base, peut-être une clé d'API, et voir ce qui se passe. C'est un échange plus équitable, et c'est la raison pour laquelle nous avons construit les hôtes compatibles avant tout le reste.