Introduction à l’univers des API

Chaque jour dans notre environnement professionnel ou personnel, nous utilisons des dizaines voire des centaines d’API sans le savoir. Que tu souhaites intégrer une carte de navigation sur ton site ou voir des informations personnalisées en fonction de ton historique de navigation, tu auras affaire à une voire plusieurs API. Alors si tu te poses des questions sur les API, tu es au bon endroit !

‍

Qu’est-ce qu’une API ?  

La base d’une API

Le terme API est l’acronyme anglais de Application Programming Interface.
C'est une interface de programmation, permettant d’accéder à une application (ex : Google Maps) ou un service (ex : données clients). Cette définition peut en perdre plus d’un c’est pourquoi nos experts QA nous ont donné une belle analogie que tout le monde comprendra. Imagine être client dans un restaurant (dans une entreprise c’est le testeur, le Product Owner, le développeur). La première chose que tu fais après avoir pris place à table est de regarder le menu des plats disponibles (le catalogue des API disponibles dans SI). Pour commander ou être servis, les actions sont réalisées par un serveur (API). Il va être l’intermédiaire entre toi et la cuisine comme une API peut le faire lorsqu'elle est sollicitée.  

L’API va avoir plusieurs fonctions dont les grandes sont :  

• Communiquer entre différentes sections du site (front et back) et/ou services (interne et externe)
• Transmettre / aller chercher de l’information dans les différentes bases de données ou encore en dehors de l’entreprise (exemple : une entreprise de recharge électrique va interroger les API que des entreprises mettent à disposition.
• Servir de lien entre 2 services qui n’ont pas le même langage informatique.  

Par exemple, 2 services ferroviaires utilisent des réseaux partagés. Néanmoins ces 2 services n’ont pas les mêmes règles de gestion. Une API va s’interposer entre les 2 pour servir de traducteur.
C’est un peu comme si lors d'un voyage, tu essaies de converser avec une personne locale qui ne parle ni le français ni une autre langue que tu connais. Il sera possible de comprendre ce qu’elle veut dire à condition que tu utilises un traducteur qui fera la passerelle entre vous 2.  

Quels sont les principaux types d’API ?

• API REST : API, née il y a une dizaine d’année, la plus populaire mais dont la sécurité est plus modeste.  Elle a une architecture basée sur HTTP et qui fonctionne avec JSON, XML, YAML...
• API SOAP : API la plus ancienne, dont la sécurité est accrue mais dont le coût est plus conséquent et l’élaboration est plus compliquée. Elle a une méthode de communication basée sur XML langage informatique strict.  

Attention, 70% des API sont créées en API REST. Les API SOAP sont utilisées pour des secteurs à risques comme le système bancaire.

Quels sont les grandes catégories d’API ?

Interne : API qui s’utilise au sein même d’une entreprise dans un environnement sécurisé (dev, recette...). Elle n’a pas pour but d’être partagée. Elle va être assez évocatrice. Les noms des micro-services seront à l’intérieur car il n’y a pas de raison de sécuriser l’API car elle se trouve déjà dans un environnement sécurisé.  

Partenaire : API qui est exposée au service BtoB comme Uber et Google Maps. Ce dernier va mettre à disposition une carte pour l’utilisation contrôlée de Uber avec une documentation pour que chaque partenaire puisse l’utiliser. Elle va avoir un degré de sécurité plus élevé. Elle va fonctionner avec un “Token” qui s’apparente à un jeton unique qui te donne le droit ou t’autorisera à réaliser diverses actions.  

Public : API accessible à tout le monde. Il suffit de prendre un lien sur internet et il va fonctionner sans être sécurisé par un mot de passe ou une accréditation. Exemple, API de RandomDog.

De quoi est constituée une API ?  

Une API est constituée de micro-services : ces micro-services vont faire de petits appels en fonction du contexte et de ce que tu veux récupérer.  
Exemple La Fnac, sur la page d’accueil, tu n'as pas loin d’une vingtaine d’appels afin de présenter les produits. Si La Fnac propose des produits personnalisés en fonction de la navigation antérieur de l’utilisateur c’est qu’elle fait appel à un micro service qui pourrait s’appeler “recommandation” et qui est lié aux cookies sur le site.
 

Les 4 appels principaux pour utiliser une API  

Il en existe plus que 4 mais 90% des actions sont réalisées par ces 4 appels d’API :

• POST : cet appel va créer ou mettre à jour la donnée en fonction des accords entre les développeurs. Exemple quand une personne s’inscrit à un service on va faire un appel POST SUBSCRIPTION pour créer une ligne dans la base de données des clients.
• GET : cet appel va permettre de lire dans une base de données pour retourner une information. Exemple, sur le site dont la personne vient de réaliser son inscription, elle recherche une image de chien. L’appel qui va être réalisé afin de montrer à cette personne l’ensemble des photos répondant à la requête sera réalisé via un appel GET
• PUT : Cet appel permet de mettre à jour la donnée. En reprenant l’exemple, si une personne après son inscription veut mettre à jour son adresse postale, les données dans la base de données vont se mettre à jours via un appel PUT
• DELETE : cet appel va supprimer des informations dans la base de données. Par exemple, si la personne qui vient de s’inscrit veut supprimer son compte totalement en appliquant ses droits RGPD, la ligne avec l’ensemble des informations de la personne va être supprimer suite à l’appel DELETE.

Attention, un cinquième appel peut s’ajouter ; PATCH. A l’inverse de PUT qui update toute une ressource en réécrivant par-dessus pour modifier une ou plusieurs informations, PATCH va permettre de modifier qu’un ou des champs spécifiques sans updater l’ensemble de la ressource.  

Exemple d’appels lors de l’utilisation d’API :
Lorsque tu souhaites utiliser l’application UBER, tu dois t’inscrire. Ton inscription va être une nouvelle ligne dans la/les bases de données via un appel POST. Suite à cette inscription, tu atterris sur une MAP, et celle-ci n’est pas codée par Uber. L’application l’affiche en faisant un appel GET avec les données de localisation. Si tu souhaites réserver un Uber, tu vas créer une nouvelle course dans la base de données “Ride” qui va créer une ligne avec l’appel POST tout en allant chercher les informations dans diverses bases de données (client/chauffeur/véhicule) via des appels GET. Enfin lorsque ta course est réalisée, le paiement va se déclencher en faisant appel au service STRIPE via son API. Lors du paiement, tu te rends compte que la carte enregistrée n’est plus la bonne. Par conséquent, tu souhaites la modifier. Cette action va être réalisée via un appel PUT.
‍

Pourquoi et quand tester les API ?  

Avant de lancer une API ou d’utiliser une API partenaire, il est important de la tester afin de :  

• Vérifier la bonne connectivité entre les services  
• Assurer la qualité des données exposées  

Exemple chez Datanumia, il est primordial pour la satisfaction client de vérifier que la donnée affichée dans la partie “mes consommations” soit bonne et cohérente avec la consommation du client. Si cela n’est pas le cas, le client va exprimer son mécontentement au niveau du service client et par conséquent va augmenter le taux d’insatisfaction.  

Il est impératif de faire régulièrement des tests que ce soit au cours de l’intégration / développement de l’API pour vérifier la qualité des données exposées ou lors d’évolutions pour s'assurer qu’il n’y a pas de régression et que les connectivités avec tous les systèmes sont toujours en place.

Que teste-t-on lors d’un test d’une API ?

Les tests vont dépendre des API et de la complexité mais en général voici une liste non exhaustive des bases à tester :  

• La donnée est correcte
• Les normes de sécurité sont activées et fonctionnelles (exemple connexion avec un TOKEN pour une API partenaire)
• Le format du message retour est cohérent (que le fichier soit bien dans le bon langage XML et non JSON par exemple)
• La disponibilité de l'API : si un système ne fonctionne pas ou si l’API a crashé.  

Ces batteries de tests sur les API sont souvent réalisés par les développeurs ou les personnes en charge de la qualité connu sous le nom de QA 😉. Il n’y a pas besoin d’avoir des compétences spécifiques pour tester une API. En revanche, la moindre erreur dans la requête ou le paramétrage peut faire échouer les tests, il faut donc faire preuve de rigueur et d'attention au détail.  

Au premier abord, utiliser un logiciel pour tester une API comme POSTMAN peut être impressionnant car l'interface contient des lignes de code. Mais quand l’API a une structure cohérente avec des intitulés cohérents la lecture devient accessible à tous.  

Quels sont les avantages et inconvénients de faire appel à des API.

Avantages de faire appel à des API :

• Permet de simplifier les développements en ne développant pas tout par soi-même
• Ajout de fonctionnalités déjà existantes
• Permet la mise à disposition d’informations sans compromettre la sécurité
• Reprendre des services existants et rester dans son cœur de métier
• Possibilité de monétiser l’API créée et ainsi avoir une source de revenu
• Documentation propre mettant en avant les appels et les retours attendus. En tant que testeur avant de tester une API il faut demander le SWAGGER. Une première documentation qui définit ce que fait l’API. Il va définir les informations requises pour faire un appel et les différentes réponses possibles (200 = bonne info ; 400 = mauvaise requête ; 500 = erreur inattendue)
• Pour les QA, faire des tests directement sur l’API via POSTMAN permet de vérifier beaucoup plus rapidement différents points du flux. Bien sûr cela ne remplace pas le test de bout en bout.  
• TEST TNR : automatiser les jeux de données, en les créant via API pour raccourcir les tests.  

Les inconvénients des API : il existe peu d’inconvénients à utiliser une API ce qui explique qu'aujourd’hui, presque l’ensemble, des entreprises digitales en utilisent.  

• Pour les entreprises qui mettent à disposition des API, la difficulté est d'estimer la valeur  
• L’usage des API impacte la sécurité des systèmes qu’il faut alors renforcer

‍

Pour conclure, les APIs sont aujourd’hui utilisées par de nombreuses entreprises pour limiter les coups de développement et permettre l’échange de données en temps réel. Alors que les APIs se généralisent il est important de connaître leurs forces et leurs faiblesses pour profiter de toutes les fonctionnalités. Tu souhaites développer tes connaissances en quality management, découvre tous nos articles sur le sujet !

Que doit-on retire de l'utilisation des API :

• Les API permettent de communiquer entre des services / sections.
• Elles permettent d'ajouter de nouveaux services sans avoir besoin de tout développer.
• Elles sont utiles et utilisées dans tous les secteurs / services car répondent à tous les besoins.
• Il est important de tester les API lors du développement mais aussi lors de l'intégration de ces dernières et lors de mises à jour.