Facebook EmaiInACirclel
Développement front-end, back-end

On va faire court 5, les API

PentaGuy
PentaGuy
Blogger

Vous avez remarqué qu’on parle beaucoup d’API ici, de leur design, de leur «gouvernance» et que sais-je encore ? J’imagine que ça doit vouloir dire quelque chose pour mal de monde mais en est-on bien sûr ? Qu’est-ce que c’est une API ? Mon défi d’aujourd’hui est de vous l’expliquer en une page. Promis, vous ne scrollerez pas sauf si vous me lisez sur votre mobile.

Application programming interface - API

Découvrez l’univers des API (Application Programming Interface) : points d’entrée, protocoles, formats d’échanges.

API c’est le petit nom de l’Application Programming Interface qui veut bien dire ce qu’il veut dire, c’est le moyen par lequel un logiciel en accède à un autre. C’est une notion assez vaste comme on va le voir avec quelques exemples mais ce qui est bien c’est que toutes les API ont les mêmes choses en commun.

Tout d’abord, il y a les points d’entrée (endpoints) qui sont les éléments d’intérêt pour le client de l’API. En effet, c’est via les points d’entrée que les fonctions du logiciel vont pouvoir être activées. Ensuite, il y a le protocole sous-jacent qui va servir au transport des requêtes et des réponses de l’API. Et enfin, il y a le ou les formats d’échanges qui servent à encoder les informations que l’API et son client vont s’échanger. Un exemple tout de suite : un service web dispose bien naturellement d’une API (sinon il ne servirait pas à grand-chose). Ses points d’entrée sont essentiellement des fonctions ou des objets/ressources identifiés auxquels on associe des fonctions. Le protocole de transport est HTTP et le format d’échange peut être XML, JSON ou YAML. Un autre exemple ? Une API très simple est celle du modèle d’acteur (oui, ça peut sembler être une obsession). L’API des acteurs est toujours la même quelles que soient les responsabilités qu’ils peuvent avoir : le seul point d’entrée est la donnée de l’adresse de l’acteur (qui l’identifie de manière univoque sur l’espace des acteurs), le protocole est celui de l’appel asynchrone avec continuation et le format d’échange est du texte encodé binaire obtenu par sérialisation des informations échangées. Encore un exemple ? Une simple DLL de Windows possède une API : des fonctions comme points d’entrée, le protocole d’appel de fonction de Windows (niveau système d’exploitation mais c’est un protocole quand même) et un format d’échange qui est une sérialisation binaire (niveau système d’exploitation).

Une API possède une fonction (faire communiquer des éléments logiciels distincts) et une forme qui restent invariantes quelles que soient leur emploi ou leur implémentation, l’API est donc un pattern (c’est même un pattern d’intégration, le plus essentiel d’entre eux d’ailleurs).

Est-ce tout ce qui définit une API ? Essentiellement oui, le reste de ce qui constitue la conception d’une API sont les politiques de l’API (mot qui est préférable à mon sens au mot gouvernance qui est vide de sens). Les politiques sont indépendantes de la nature de l’API et nous allons voir pourquoi. Quelles sont les politiques possibles ? Votre service web ne doit être accédé que par des abonnés à votre service ? Politique d’accès et d’authentification. Les données échangées doivent être cryptées ? Politique de sécurité des échanges. Les points d’entrée peuvent changer de signature ou d’identité ? Politique de compatibilité ascendante. Votre service web est critique et doit être accessible 24/24 7/7 ? Politique de haute disponibilité, etc., etc.

De manière générale, la conception essentielle d’une API ce sont ses points d’entrée, son protocole de transport et ses formats d’échanges. Le reste ce ne sont que les politiques et, comme le diable se cache dans les détails, ce sont les politiques qui requièrent le plus grand effort de design.

J’arrive au terme de la limite d’une page que je suis auto-imparti. Il y a encore matière à traiter : le style REST, les patterns d’architecture spécifiques aux API ou encore la documentation des API. D’ici là, n’hésitez pas à partager, commenter ou apprécier cet article s’il vous a plu.

 

Retrouvez les précédents articles de la série « On va faire court »

On va faire court 1, le chiffrement asymétrique

On va faire court 2, l’échelle Technology Readiness Levels

On va faire court 3, la représentation digitale des nombres

On va faire court 4, les transactions


2 Commentaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *