Last update: 15-04-2021 05:59
16'13"

APIApplication Programming Interface

Voilà des années que je construis des APIs, d'une manière ou d'une autre.

Écrire un API, dans sa plus élémentaire philosophie, ce n'est rien d'autre qu'écrire du code pour d'autres, y compris pour cet autre soi-même qui demain aura besoin du code écrit hier, du code qui pourra évoluer selon les besoins fonctionnels ou selon les contraintes techniques.

Écrire une librairie, ce n'est guère différent d'écrire un API, philosophiquement j'entends. Écrire une DLL (Dynamic Link Library) c'est encore pareil. Écrire des objets COM (Component Object Model) ou DCOM (Distributed Component Object Model) procédait toujours de la même démarche.

Écrire un API, dans sa plus élémentaire philosophie, ce n'est rien d'autre qu'écrire du code pour d'autres, y compris pour cet autre soi-même qui demain aura besoin du code écrit hier.

Un bref historique

Les APIs ne sont pas vraiment un concept nouveau en informatique. Déjà dans les années 60 des développeurs ont créé des bibliothèques de routines standardisées. J'ai moi-même acheté des librairies C ou Assembleur pour accélérer mon propre développement dans nombre de cas, bibliothèques de routines et fonctions que je garde bien précieusement comme autant de pièces de musée.

Avec la généralisation des ordinateurs connectés — en 1989, au sein de la société FastWrite, aucun ordinateur n'était connecté : les cartes réseaux étaient chères et les standards réseaux pas encore ce qu'ils sont aujourd'hui — on a vu l'émergence de règles qui permettaient d'appeler du code qui se trouvait sur d'autres machines grâce, par exemple, aux appels RPC (Remote Procedure Call)

Quelles que furent les solutions qui avaient au moins le mérite de leur inventivité, cela restait quand même complexe et surtout … les deux parties, celui qui appelle le service et celui qui y répond, continuaient à devoir utiliser le même langage. Ce qui était vrai avec les librairies, dynamiques ou non — des DLLs (Dynamic Link Library) par exemple — continuait à l'être pour des composants COM (Component Object Model) et DCOM (Distributed Component Object Model).

Puis, dans les années 90, on en est arrivé à découpler le tout. D'un côté l'appelant, de l'autre, l'appelé. Dans le langage technique, le «client» et le «serveur». Le client pouvait alors fonctionner dans un langage et le serveur dans un autre.. Deux choses importaient :  (1) standardiser l'appel (essentiellement le passage des paramètres) et (2) standardiser la réponse (le résultat renvoyé).

Ce découplage a donné naissance à l'informatique moderne comme on la connait aujourd'hui avec des APIs en pagaille, une pléthore de services dans laquelle se sont jetés tous les grands que nous connaissons: Google, Amazon, Microsoft, Spotify, Deezer, Apple, ... Désormais ce sont des millions de services qui sont disponibles partout sur Internet puisque tout est découplé et qu'il suffit de s'entendre sur le passage des paramètres et la réception de la réponse, une simple affaire de format en somme.

C'est précisément cette évolution de l'informatique moderne qui a permis d'envisager des paradigmes qui nous semblent évidents aujourd'hui. Prenons ces paradigmes qui sont les pierres angulaires du mouvement DevOps comme «Continuous Integration» et «Continuous Delivery» et vérifions ce que nous en dit le ngram viewer :

Poussons la réflexion plus loin et voyons quel fut le démarrage du terme "OpenAPI" … :

On remarque que les courbes se juxtaposent assez bien et que leur changement d'inflexion se situe grosso-modo au même moment, soit 2012–2013.

Des produits comme Maeven et Jenkins datent de 2004. Comparez ces naissances au pic de la courbe ngram de «Web Services» (et vous pourrez aussi, à titre d'exercice personnel, comparer ce pic avec celui du mot «interopérabilité») : d'abord une vue très étalée dans le temps (ce qui fait ressortir le pic de 2005), et puis une courbe plus ramassée sur les années (ce qui nous permet de mieux mettre en évidence la période de «gloire»)…

N'est-ce pas frappant ?

En 2011, chez BNP Paribas, alors que nous développions la plateforme Internet & Mobile Banking, diverses équipes travaillaient à la réalisation d'APIs. Cela n'a pas discontinué jusqu'en 2014.

Lorsque je suis retourné chez BNP Paribas en 2016, les équipes parlaient désormais de «API First» comme peu de temps avant «Mobile First» !

Voyons la courbe «Docker»:

Il n'y a pas de doute : quelque chose s'est bien produit en 2012 — 2013 , quelque chose qui a été rendu possible par l'apparition de plus en plus généralisée des APIs et des Web Services en 2004 — 2005.

Achevons la démonstration avec le terme «DevOps»:

Rebelote ! Même le Cloud suit la même tendance. D'ailleurs comment envisager son utilisation sans une kyrielle de services agencés en paquets fonctionnels.

La conclusion s'impose d'elle-même : à peu de choses près la mise au point d'APIs et le mouvement DevOps vont main dans la main ! Le premier a permis le second. On comprend dès lors à quel point le développement et l'utilisation d'APIs imprime la direction dans laquelle va l'informatique du jour.

Et malgré cette direction très marquée de très nombreuses organisations n'ont pas encore complètement embrassé le modèle. Il faut dire que si l'utilisation de services est entrée dans les habitudes des équipes de développement, la mise au point et la création d'ensembles de services ordonnés est affaire plus compliquée. Souvent plus compliquée que ce qu'on imagine. Une affaire dans laquelle s'imbriquent d'autres notions comme — exemples choisis — SOA (Service Oriented Architecture) et ESB (Enterprise Service Bus). Cette imbrication est à ce point forte que les notions ne vont plus l'une sans l'autre : ESB, une notion qui s'apparente à la mise en place d'une véritable colonne vertébrale digitale.

Les trois phases

La mise au point d'APIs, qui peuvent d'ailleurs faire appel à des services d'APIs externes, nécessite une réflexion en profondeur du métier de l'organisation, une sorte de dépeçage intellectuel. Vous ne faites plus appel à des "analystes" ! Vous faites appel à des "anatomistes" et "chirurgiens", des collaborateurs qui vont étudier en profondeur les détails de votre organisation. Tout comme en médecine vous avez des spécialistes du cœur, d'autres des poumons, du foie, etc. vous allez voir l'émergence de spécialités distinctes et, dès lors, d'APIs distincts également.

C'est furieusement intéressant de voir cela se produire au sein d'une organisation et, pour tout dire, cette marche en avant est un marqueur de maturité. Voyons cela avec un peu de hauteur.

Tout d'abord se fait sentir le besoin de mettre un API au point. Cela se fait dans l'enthousiasme et avec fougue. Quelques passionnés se lancent dans l'aventure. Ils sont remuants et ont besoin d'abattre des murs pour en construire d'autres. C'est un peu le temps des héros, une période que j'appelle celle des vaisseaux par référence au système sanguin : on découvre les interconnexions d'un vaste entremêlement.

Puis vient le temps où la création débridée doit être encadrée. C'est une période qui marque un autre degré de maturité et dont la difficulté essentielle n'est pas l'encadrement technique mais plutôt l'encadrement humain. C'est l'époque où les bouillonnants de la première heure peuvent se sentir dépossédés de leur création or … ils sont la force motrice du mouvement. La meilleure chose qui puisse se passer c'est que ce soient ces sémillants programmeurs qui érigent eux-mêmes les règles de l'encadrement nécessaire. J'appelle cette période celle du cœur par référence à la découpe en organes essentiels et à l'émergence de spécialités.

Enfin, vient la période de l'organisme. Elle fait donc suite aux periodes des vaisseaux et du cœur. Tout communique, aucun des organes n'est isolé. Chaque spécialité fait partie d'un grand tout et si chacune a son propre écosystème, l'organisme (entendez l'organisation) est elle-même un écosystème. C'est une nouvelle étape dans la maturité, une étape où on se rend compte que l'amélioration d'un écosystème isolé ne se traduit pas nécessairement par un progrès, par un avantage pour l'organisme dans sa globalité. C'est une autre de ces étapes essentielles qui est fortement liée à l'amplification naturelle de la complexité des systèmes. Toute complexité croissante est assortie d'un pendant économique. C'est le moment où les processus et les règles pour tout indispensables qu'ils soient représentent néanmoins un poids supplémentaire. La maîtrise bicéphale, tant donc économique que technique, caractérise cette période.

Trois grandes phases dans la création d'APIs :  la période des vaisseaux, la période du cœur, puis la période de l'organisme. Ces trois périodes marquent la progression de maturité de l'organisation dans l'émergence du paradigme lié à la création d'API(s).

Tout ceci vous ne le verrez à l'œuvre que si l'organisation s'est lancée dans la création de son propre API ou ensemble d'APIs.

Besoins internes et besoins externes

Imaginons que vous ayez décidé de vous lancer dans la création et le maintien d'un API, voire même d'un ensemble d'APIs. Prenons ceci comme un fait acquis. Après être passé par les différentes phases décrites ci-avant, voire même pendant l'une des phases citées plus haut, il se pourrait que la question de servir des besoins externes se fasse sentir. Dans ce cas, vous ne vous contentez plus de servir une communauté de programmeurs internes à votre organisation mais vous décidez de satisfaire une communauté externe à votre organisation. Tout à coup vous entrez en confrontation avec des considérations totalement nouvelles, a ce point nouvelles d'ailleurs que ce qui était considéré comme acquis est chamboulé dans ses plus infimes détails : l'infrastructure physique, la sécurité, la publication de la documentation, les conditions de testing, etc.

Les besoins des développeurs externes ne sont pas nécessairement ceux des développeurs internes. Le besoin de rétrocompatibilité stricte de l'API mais également la nécessité d'adapter l'API pour les nouvelles fonctionnalités souhaitées par désormais les «clients» ont un coût non négligeable et peuvent impacter très sensiblement la vitesse du projet.

Tout à coup vous entrez en confrontation avec des considérations totalement nouvelles.

L'impact que cela crée peut être à ce point colossal que la question de savoir qui servir en premier, développeurs internes ou développeurs externes, fait sens. À vrai dire, les deux approches se côtoient.

Je vais brièvement décrire plusieurs paradigmes qui se feront plus que probablement jour. Mes descriptions ne se veulent ni détaillées ni exhaustives.

Le paradigme des versions

La rétrocompatibilité stricte est une partie du contrat que vous allez devoir honorer. Il ne s'agira pas de développer un service et d'en changer l'interface quand cela vous convient. Quand vous étiez seul il suffisait de modifier toutes les parties appelantes pour vous garantir que le nouveau service, ou le service modifié, n'allait pas fracasser le code. Avec des développeurs externes, pas possible de jouer la partie de cette façon. Il faudra en passer par des versions différentes de vos APIs, ce qui se gère avec une multiplicité de endpoints. Voici un exemple fictif d'appel à deux versions différentes du même service:

    https://api.monbeaudomaine.com/V1/accounts/12345
    https://api.monbeaudomaine.com/V2/accounts/12345

Comme on le constate, on multiplie les endpoints, une obligation qui n'était pas nécessairement la vôtre lorsque l'API n'était utilisé qu'en interne. Cela ne semble pas bien grave, mais prenez conscience que ceci entraînera une gestion supplémentaire.

Le paradigme du dispatching

Une fois que vous multipliez les versions perce la nécessité d'oragniser le versioning ET leur support. Lorsque vous en serez à la version 10 de votre API, il y a gros à parier que vous ne voudrez plus supporter la version 1.

Vous devrez probablement router les appels vers une autre version ou générer des codes d'erreur spécifiques (une nouvelle obligation que cette gestion d'erreurs).

Les questions de performance et de congestion possible se font jour également : les endpoints internes peuvent ne pas être les endpoints exposés. Bref … il va falloir router le trafic en interne de votre propre réseau et il faut gérer tout cela. Il se peut même que la charge interne sur votre réseau soit devenue à ce point importante qu'un upgrade de protocole HTTP soit dévenu indispensable, un passage à HTTP/2 par exemple !

Le paradigme du testing

Prenez l'exemple d'un API de paiement. Il est sûr que vous ne pouvez pas disposer exactement des mêmes conditions d'utilisation que l'ensemble de vos utilisateurs. Vous allez alors très comprendre que la mise au point d'une nouvelle version d'un API nécessite la mise en place d'une sandbox, voire de plusieurs sandboxes. Encore une chose à gérer !

Même si vous n'en êtes pas encore à développer une nouvelle version, les programmeurs externes voudront pouvoir tester leur propre implémentation de votre API. Personnellement, pour me permettre d'offir des sites web avec traitement de paiements en ligne, j'utilise Mollie. Voilà un API particulèrement bien fait qui me permet de tester ma propre implémentation de leur API en mode "test" ou bien d'activer la version "live". Dans le premier cas, toutes les transactions auxquelles je me suis livré sont enregistrées dans un ledger de test. Vous allez devoir probablement passer par la même fonctionnalité et vous verrez que c'est là encore un aspect nouveau à traiter/gérer.

Le paradigme de la sécurité et de l'identification/autorisation

Tant que vous n'étiez qu'entre développeurs internes, la question de la sécurité ne se posait pas, ou du moins pas avec autant de poids. Maintenant, plus question de cela. Chaque appel doit être identifié et dûment autorisé. C'est une nouvelle gestion à laquelle vous ne pourrez échapper.

Le paradigme de la qualification des données

Tant que vous n'étiez qu'à développer un API pour utilisation interne, de simples règles écrites au règlement du travail pouvaient suffire pour codifier les accès, notamment aux données à caractère privé. Désormais, avec des appels en provenance de développeurs extérieurs vous allez devoir trouver les dispositions techniques qui vous permettent de respecter les règles GDPR. Un nouvel exercice !

Le paradigme du caissier

Voci probablement mon préféré ! Le paradogme du caissier. Si vous considérez votre organisation comme un supermarché auxquels se rendent de nombreux clients, vous voudrez probablement qu'ils passent à la caisse ! À vrai dire, même si vous ne servez que des programmeurs internes vous voudrez quand même qu'ils passent à la caisse d'une manière ou d'une autre : je reviendrai sur le sujet.

Le paradigme du caissier … De quoi s'agit-il ? Ben, en gros, il faut penser à cela comme on pourrait penser que cela fonctionne à une caisse de grand magasin. Il s'agit de "payer" ce que avec quoi on repart.

Celui qui passe à la caisse peut avoir des "bons de réduction", des "articles gratuits", des "actions promotionnelles", une "carte de fidélité", etc.

Par exemple, si vous utilisez les services de Google ou de Microsoft ou d'Amazon … en fonction de qui vous êtes et du compte dont vous disposez auprès d'eux (par exemple un compte "gratuit", très utile pour les développeurs) vous payerez ou non les services que vous utilisez. Peut-être même que le prix est déterminé en fonction de volumes mensuels, de volumes quotidiens ou même de volumes à l'heure, voire une combinaison de toutes ces possibilités. C'est un point de gestion essentiel.

La clef d'API est le Graal qui permet l'identification de qui se présente à la caisse mais il existe d'autres méthodes dont par exemple l'authentification suivie de la requête d'un token d'utilisation des services, token qui sera utilisé dans les appels API subséquents.

Là … il y a 2 notions de "compte". Il y a le "User Account" (notion user account (Q3604202) — entity representing a user of a computer system or network service) et il y a le "Account" ( account (Q508295) — central data structure in the practice of accounting). Il y a fort à parier que voilà au moins une nouvelle notion à intégrer dans la gestion de vos APIs. Pour moo, ce fut la notion Q508295 !

C'est très précisément ici que se révèle l'utilité de ce paradigme, même quand vous développez uniquement pour l'interne ! Avec la mise en place de ce paradigme vous pouvez désormais mettre en place une véritable usine de statistiques d'accès (couple requête-réponse). Équipé de ce paradigme, vous pouvez désormais juger objectivement du succès de vos services, tant dans l'aspect requête que dans l'aspect réponse. Une mesure objective permet de vous concentrer sur les services vraiment utilisés (ceux qui comptent à priori). Peut-être découvrirez-vous que certains services, de manière surprenante, sont sous-utilés.

Avec ledit paradigme du caissier, il vous est même possible de vous livrer à une refacturation interne aux départements qui sont consommateurs de vos services car, croyez-le bien, vos services et leur mise au point/entretien ne sont pas gratuits. Disposer des informations statistiques (quoi, qui, quand, où) s'avère particulièrement important lorsqu'il s'agit de préparer les budgets : il ne s'agit plus de requérir des budgets basés sur des opinions mais bien d'exposer des faits. Du moins pour cette partie.

… et il y a d'autres paradigmes !

Vous ajouterez d'autres paradigmes vous-mêmes qui correspondent au contexte de l'organisation où vous exercez votre talent.