Les API, mais qu'est-ce que c'est?

Qu'est ce qu'une API?

Cette question n'est pas nouvelle. On me l'avait déjà posée dans le cadre professionnel. La réponse fut laborieuse malgré toute la documentation du monde. Ce sujet me revient lors de la lecture d'un post sur Linkedin.

L'auteur du post tente d'expliquer ce qu'est une API à un enfant de 10 ans.

Un membre poste le commentaire suivant:

En soi, les deux intervenants ont raison. Une API est bien une interface qui permet à deux systèmes indépendants de communiquer et s'échanger des données.

Mais ça veut dire quoi API?

API signifie Application Programming Interface. En français, Interface de Programmation d'Application.  

Il est peut-être bon d'expliquer ce qu'est une interface, non? 

Le Larousse dit :

• Plan ou surface de discontinuité formant une frontière commune à deux domaines aux propriétés différentes et unis par des rapports d'échanges et d'interaction réciproques.
• Limite commune à deux systèmes, permettant des échanges entre ceux-ci.
• Surface séparant deux phases chimiques non miscibles.
• Dispositif permettant la liaison de deux circuits électroniques ne devant pas avoir de répercussion l'un sur l'autre.
• En informatique, jonction entre deux matériels ou logiciels leur permettant d'échanger des informations par l'adoption de règles communes ; module matériel ou logiciel permettant la communication d'un système avec l'extérieur.
• Personne qui assure l'échange d'informations entre deux domaines, deux services, deux personnes : Faire l'interface entre le producteur et le consommateur.

Donc, une interface est la limite, la frontière entre deux domaines distincts aux propriétés différentes, unis par des rapports d'échanges et d'interaction réciproques par l'adoption des règles communes, ne devant pas avoir de répercussion l'un sur l'autre.

On ne se rend pas vraiment compte mais nous sommes entourés d'interfaces. Nous utilisons des interfaces à longueur de journée. Le clavier, la souris, l'écran tactile sont des interfaces. La connectique fourmille d'interfaces : HDMI, USB, MIDI, les prises électriques mâles et femelles, …

Les interfaces les plus connues sont probablement celles qui nous permettent de conduire une voiture. Le volant, le changement de vitesse et les pédales sont des interfaces. On peut affirmer sans trop se mouiller que, quelque soit la voiture dans laquelle vous embarquez, vous devriez être capable de la conduire. Pourquoi? Parce toutes les voitures implémentent la même interface, elles adoptent des règles communes. Règles que vous connaissez si vous pouvez conduire une voiture. Quelle tête feriez-vous si demain, le volant était remplacé par une manette de Playstation?

D'ailleurs, les interfaces pour piloter un avion ou un hélicoptère, ne sont pas les mêmes que celles de la voiture. Mais je suppose que les interfaces de pilotage des avions sont les mêmes pour tous les avions, et qu'il en va de même pour les hélicoptères. 

En programmation orientée objet, les interfaces sont des contrats qui obligent la classe qui y souscrit à implémenter les méthodes définies dans l'interface. De cette façon, toute instance de cette classe indique à tous les autres objets qu'ils peuvent discuter avec elle en utilisant les méthodes définies dans l'interface et en sachant à quoi servent ses méthodes. C'est comme pour la voiture. Elle implémente l'interface volant. Tout conducteur saura comment utiliser cette interface. Idem pour l'interface changement de vitesse.  

Il me semble qu'on a fait le tour de l'interface.

Les API ne sont pas nées avec le web

Souvent, le concept d'API est confondu avec celui de Web Service. C'est bien normal.  Un Web Service est une API mais une API n'est pas forcément un Web Service. 

Les systèmes d'exploitation exposent des API. Cela permet aussi aux différentes parties de l'OS de communiquer entre elles. Les APIs systèmes sont la pierre angulaire du développement logiciel depuis des décennies. L'API Win32, par exemple, remonte aux premiers temps de Windows NT (milieu des années 90).
Les développeurs de logiciels utilisent les APIs pour accéder aux périphériques ou au gestionnaire d'interface graphique natif. En fait, les APIs permettent une compatibilité et une réutilisation à travers les différentes versions d'applications, voire des générations de systèmes d'exploitation.

La restauration d'un vieux jukebox Seeburg à l'aide d'un Arduino et d'une carte lecteur MP3 est une excellente comparaison. La machine a été vidée de ses entrailles électromécaniques et de sa pile de 45 tours. L'ensemble des câbles a été remplacé par un Arduino et une carte son capable de stocker des fichiers audio compressés (voir la vidéo ci-dessous). Le bricoleur a cependant gardé intactes la carcasse externe et le système de boutons de sélection. Tout le mécanisme interne caché à l'utilisateur a été totalement remplacé, alors que le boitier externe, ainsi que les boutons et les lumières, ont été conservés pour préserver l'expérience de l'utilisateur. 

Une API est un peu comme cette vieille carcasse de jukebox qui continue, malgré les modifications radicales internes, à fournir la même d'interface. Cette caractéristique amène une stabilité malgré les mises à jour.

Comment en est-on arrivé aux services web?

Ces APIs sont localisées sur la même machine que les programmes qui y accèdent. Disons à présent que vous développez une application qui contient une librairie servant d'API. Et c'est via cette API que vous accédez à une base de données distante. Jusque là, pas trop de souci.

Bien que cela pourrait amener quelques failles de sécurité.

En effet, à l'époque où les applications compilées étaient installées localement, il était habituel de valider les données côté client. La librairie API validait les données et … Enregistrait ces données directement dans la base de données distantes. Dans cette architecture, nous pourrions probablement sans trop de peine nous faire passer pour l'application et envoyer des données invalides, voire des injections SQL directement dans la base de données ! 

Ne croyez pas que ce cas de figure soit exagéré, j'ai vécu cette situation. Une application bureau avait été développée et tournait sur plusieurs ordinateurs du département. L'application contenait toute la logique métier ainsi que les relations de la base de données. La base de données tournait sur le SGBDR MySQL avec le moteur MyISAM. Et la configuration d'accès à la base de données se trouvait en clair, sans chiffrement, dans un fichier texte, accessible à l'utilisateur. L'identifiant de connexion était le même pour tous les utilisateurs. La gestion des droits était effectuée dans l'application. Donc, une fois cet identifiant récupéré, il suffisait de se connecter avec un logiciel tel que MySQL Workbench et la base de données était accessible sans les contraintes de l'application cliente. 
Cerise sur le gâteau : diverses versions de l'application coexistaient au sein de la section. Ce qui engendrait parfois des situations inattendues.
De surcroît, le site web devait également valider les données et appliquer une partie de la même logique métier. Devoir maintenir un même code dans deux applications va à l'encontre de la philosophie DRY (don't repeat yourself).

Ce cas démontre que des problèmes arriveront dus à :

• La dissociation de la logique métier de la base de données;
• L'absence d'une politique efficace de mise à jour des nombreuses instances de l'application;
• La sécurité poreuse et défaillante.

L'architecture représentée ci-dessus force une maintenance de plusieurs applications et chacune contient la logique métier. Donc si cette dernière doit être modifiée, il faut agir sur minimum 3 applications. Tout le domaine métier est décentralisé dans chaque application. 

Comment pallier tous ces problèmes?

Web API

Les applications web sont centralisées. Tous les clients se connectent à une même application. Lorsque l'application est mise à jour, cela est instantané pour tous les clients. Le problème de divergence de version est réglé.

La maintenance du code est centralisée. Il n'y a plus une API pour le logiciel bureautique et une API pour l'application web. Toutes les applications, qu'elles soient web, mobiles ou bureautiques, se connectent à une seule version du code.

La logique métier est rapatriée au plus près de la source de données, en diminuant ainsi les risques de failles de sécurité dues au transfert de données sur le réseau.

Précisons quand même que s'il n'y a plus de réseau, il n'y a plus d'API web et donc plus d'application…  Il est donc parfois intéressant de songer à développer une application qui sera capable de fonctionner de manière déconnectée et qui synchronisera les données une fois la connexion rétablie.

En conclusion

Utiliser les API, qu'elles fussent d'un OS, d'autres applications ou simplement dédiées à un domaine d'expertise, est avant tout une méthodologie qui consiste à ne pas réinventer la roue. Mais c'est également se baser sur des fonctionnalités éprouvées. 

Une API, c'est aussi une membrane à perméabilité sélective qui protège et cache les processus internes de l'environnement extérieur, tout en autorisant des échanges contrôlés d'informations de et vers l'environnement extérieur, permettant l'accomplissement des processus internes. Pour l'anecdote, ceci m'a été fortement inspiré par la description du fonctionnement d'une membrane cytoplasmique. 

Les API web ont connu un tel essor grâce à l'augmentation du débit des réseaux publiques et la diminution du coût d'accès à ceux-ci. À tel point qu'on diffuse la musique et les films depuis internet.

Ces services web sont devenus la norme dans le développement d'applications web mais pas que, ces services sont également utilisés dans les applications bureau et mobile. Il est certain que l'usage de services web est amené à durer

Il est dès lors plus simple de centraliser la logique métier et toute la sécurité  sur des serveurs distants. La mise à jour du code est instantanée et mondiale. Plus question de sniffer le réseau ou de faire de la rétro-ingénierie pour usurper des permissions et envoyer des données incorrectes. La sécurité est réalisée sur les serveurs distants. Attention, cela ne veut pas dire qu'il n'y a plus de problèmes de sécurité. Cela veut juste dire qu'il est plus compliqué pour un hackeur de frauder le système.