De nos jours trouver une API externe permettant d’améliorer la qualité de son service est devenu très facile. De plus en plus d’entreprises mettent à disposition des APIs. Problème : de nombreux développeurs/CTOs se lancent dans l’intégration alors que cette dernière ne devrait être en fait que l’ultime étape ! Avant cela il vous faut déterminer si la qualité de l’API répond à un minimum d’exigences. Voici comment je m’y prends personnellement. J’espère que cela aidera d’autres CTOs et développeurs.
Qualité des données
De nombreuses APIs exposent des données vous permettant d’enrichir votre propre système (ce n’est pas le cas de toutes les APIs bien entendu, Stripe n’est pas une API d’enrichissement par exemple). Il est essentiel que vous vous assuriez de la qualité de ces données. Cela va vous prendre pas mal de temps et je sais déjà que vous n’aimez pas les tests ! Moi non plus, mais néanmoins vous ne pouvez pas vous soustraire à la création d’un scénario de test rigoureux ici. Si vous réalisez que la qualité des données fournies n’était pas suffisamment bonne seulement deux semaines après avoir fini votre intégration, croyez-moi vous le regretterez…
Documentation
Je suis récemment tombé sur une API qui exposait des données de grande qualité (bien meilleure que ce proposait la concurrence selon moi), mais sa documentation était… un cauchemar ! En réalité il n’y avait pour ainsi dire pas de documentation. Par ailleurs l’API ne respectait pas toutes les conventions REST. Comment pouvez-vous réussir à intégrer une API externe si les codes erreurs ne sont pas proprement documentés ? Hé bien l’unique solution qu’il vous reste dans ce cas est de tester encore et encore l’API afin de comprendre son fonctionnement. Le rétro-engineering peut être amusant mais demande aussi beaucoup de temps. Rappelez-vous que dans le cas d’une API vous n’avez pas de dépôt GitHub à explorer puisque le code source n’est pas disponible… Une mauvaise doc est systématiquement synonyme de perte de temps pour les devs, et sûrement de mauvaises surprises à moyen terme.
Bibliothèques
Est-il possible d’intégrer l’API via une bibliothèque disponible dans votre langage favori ? En tant que développeur Python et Go je suis toujours enchanté lorsque je tombe sur une API qui offre une lib Python (je sais qu’en ce qui concerne Go je peux oublier pour l’instant). Cela peut vous faire gagner pas mal de temps, mais avant tout assurez-vous que la bibliothèque est mûre et couvre toutes les fonctionnalités de l’API (pas toujours le cas).
Notoriété de l’éditeur
La notoriété peut vous aider à éclairer votre choix et éviter les mauvaises surprises avec votre API à l’avenir. Par mauvaises surprises j’entends interruption de service, régression de certaines fonctionnalités, ou même arrêt définitif du service… Vous pouvez en partie éviter ces écueils en vous posant les questions suivantes :
- est-ce que cette API est connue sur le net (en général si vous trouvez peu d’information, fuyez) ? Trouvez-vous de nombreux articles/tutoriels parlant de l’API ? Ces articles sont-ils élogieux ?
- des entreprises réputées l’utilisent-elles ?
- si l’entreprise a développé des bibliothèques dédiées, sont-elles bien notées sur GitHub ? Les problèmes remontés sur GitHub sont-ils traités régulièrement ?
- y a-t-il eu des mises à jour récentes de l’API ou la dernière mis à jour a-t-elle eu lieu il y a longtemps ?
Support technique
Assurez-vous que quelqu’un réponde à vos questions rapidement par email lorsque vous rencontrez un problème et que la réponse est pertinente. Si vous êtes basé en Europe et que l’API est éditée par une entreprise américaine, assurez-vous que le décalage horaire ne pose pas de problème.
Respect des conventions
A mon humble avis, toute API sérieuse aujourd’hui se doit d’être une API RESTful. Si l’API que vous affectionnez ne respecte pas les conventions REST, alors soyez méfiant. Toutefois gardez à l’esprit quel le standard REST n’est pas clair sur tous les sujets et que chaque API peut avoir sa propre déclinaison (codes HTTP, encodage des requêtes POST, …). Il n’empêche que vous devez lire la documentation attentivement et vous assurer que vous ne constatez pas de pratique trop originale. L’originalité vous ralentira…
Prix
Bien entendu le prix est de première importance. Mais attention la tarification d’une API n’est pas toujours facile à comprendre. Allez-vous être facturé au mois pour un nombre illimité de requêtes ? Facturé à la requête ? Dans ce second cas allez-vous être facturé deux fois pour 2 requêtes identiques (dans le cas d’une API d’enrichissement) ou la seconde requête sera-t-elle gratuite ? Serez-vous facturé pour une requête ne retournant aucun résultat (HTTP 404) ? Assurez-vous de bien comprendre toutes ces implications.
Qualité de service (QoS)
La qualité de service est très importante. Votre but est de travailler avec une API aussi rapide que possible et avec le moins d’interruptions de service possible. Malheureusement il ne s’agit pas de performances faciles à tester. En effet la qualité de service varie avec le temps, et de nombreuses APIs offrent deux niveaux de QoS différents selon que vous utilisez la version gratuite ou payante… Parfois vous pouvez même choisir entre différents abonnements avec différents temps de réponse.
Support des requêtes parallèles
Selon la façon dont vous prévoyez d’intégrer l’API, vous pouvez avoir envie d’accélérer les choses en consultant l’API via plusieurs requêtes simultanées au lieu du comportement séquentiel classique. Personnellement j’utilise Golang pour cela. Si c’est le cas soyez vigilant : de nombreuses API ne supportent pas les requêtes parallèles et lorsque c’est le cas elles imposent nécessairement une limite. Dans ce cas assurez-vous d’avoir demandé à l’éditeur quelle était cette limite (pas toujours mentionné dans la doc) et adaptez votre script en fonction.
Cet article sera un bon mémo pour moi, j’espère que pour vous aussi !