Twitter, Facebook, Uber… tous les jours vous utilisez des APIs, peut-être sans le savoir : Programmable Web en recense plus de 16 000. Pour faire le point sur les APIs et leur rôle dans la transformation digitale de l’économie, nous avons rencontré Mehdi Medjaoui fondateur d’API Days (voir notre compte-rendu sur API Days Paris) et co-fondateur de OAuth.io.

Dans la première partie cette interview, nous avons abordé le rôle des des API et le changement culturel que représente leur ouverture. Nous discutons aujourd’hui de la généralisation du protocole REST, de la tendance des microservices, et du nécessaire équilibre entre automatisation et désautomatisation dans la conception des API.

Quelle est la tendance actuelle sur la façon de faire les API ? Est-ce qu’il y a une normalisation ?

« The next big thing is small » :

Depuis 10 ans environ la tendance est d’aller vers le plus petit, le plus léger, et notamment le protocole REST, qui fonctionne sur la bases de ressources. On part du principe que tout est une ressource sur le web, et on navigue à travers les URL pour trouver chaque ressource, qui est liée aux autres par des liens URL. Il y aussi JSON depuis 2008, un langage d’écriture de données issu de Javascript, mais plus léger, qui à la particularité d’être lisible facilement par les humains et les machines, et qui s’inscrit dans cette tendance. Plus petit, plus léger : les microservices répondent complètement à ces impératifs. L’idée est qu’au lieu de concevoir de grosses plateformes APIs, qui font plein de choses, il s’agit de se focaliser sur des APIs plus spécialisées, qui ne remplissent qu’une seule fonction. Les API sont ainsi découpées en une multitude de petits services découplés les uns des autres.

Quels sont les avantages de l’approche microservices ?

Il est plus simple de comprendre ce que fait chaque API, il y a donc moins de risque de se tromper. Et chaque brique être interchangeable quand c’est nécessaire. Dans “The design of everyday things”, Donald Norman explique que dans un cockpit d’avion, chaque bouton a une seule fonction car il est important dans un contexte de production de comprendre ce qui se passe derrière chaque mécanisme. C’est la même chose avec les APIs dans le cadre des microservices : une API, une fonction. En transformant des monolithes en micro services, on facilite le refactoring. Mais cela suppose une gestion de l’automatisation très différente : il faut gérer des dizaines ou des centaines de services qui doivent tous être documentés, mis à jour, maintenus et fonctionnels. Il y a donc un juste milieu à trouver pour chaque entreprise entre l’inertie des APIs monolithiques et la gouvernance des microservices.

Mehdi Medjaoui lors des API Days

Quelles technologies dominent sur le marché ?

REST et JSON représentent la très grosse majorité des nouveaux services, mais cela dépend aussi du secteur. Dans la finance, on a plutôt du SOAP XML pour tout ce qui est legacy, idem dans le transport aérien…par contre, sur tous les nouveaux business, les startups on est souvent sur du REST et JSON. Et puis il y a GraphQL (créé par Facebook en 2015) qui émerge : en France, Allociné, le ClubMed et 20 minutes l’utilisent déjà. Le souci de REST, c’est que quand il faut requêter beaucoup de ressources à la fois, on multiplie les appels au serveur, et potentiellement on le surcharge. GraphQL fonctionne suivant une logique différente, qui permet de requêter beaucoup de données en une seule fois, avec une seule requête sur un seul endpoint. Cela a permis par exemple d’économiser jusqu’à 60% de ressources serveurs dans à Github, première API publique en GraphQL. Cependant les développeurs sont tellement habitués aux interface REST qu’ils ont beau utiliser GraphQL en interne, ils ont gardé API REST par dessus. C’est ce qu’on appelle une “API facade”..

Quelles sont les activités nécessaires lorsqu’on met en place une API ?

Kin Lane, qui tient le blog API evangelist, a dressé une liste permettant de mesurer la maturité de son API. Ce sont les “building blocks” d’une API. Prenons l’exemple de la documentation : avez-vous un quick start? Avez-vous des exemples? Avez-vous des morceaux de code qui peuvent être copiés collés? Est-ce que vous avez un support ? Un compte twitter? Comment faites vous vos tests? Kin Lane a ainsi identifié 80 étapes : savez vous qui utilise l’API ? Combien d’appels sont faits? Quelles sont vos APIs critiques ? Comment monitorez vous votre performance? Cela montre bien que la réflexion est une étape indispensable à l’automatisation (voir également le livre blanc de la documentation des API).

Entre automatisation et désautomatisation, il y a un équilibre à trouver ?

La désautomatisation est encore un sujet très nouveau : pour beaucoup de développeurs ou de managers, le seul mandat c’est d’automatiser. Comme Mike Amundsen , Directeur de l’Architecture de l’API Academy (CA Technologies) , le souligne, quand certaines sociétés se targuent de mettre du code en production 300 fois/jour, cela montre une certaine dérive. Il n’y a plus de vision, on pilote à vue. Il faut trouver un équilibre entre une mise en production tous les 3 mois et 300/jour. Mike Amundsen préconise 3 couches : une couche logicielle conçue pour le long terme, une couche API à moyen terme (qui ne bouge pas pendant 1 à 3 ans), et les microservices (2 semaines à 6 mois). On ne peut pas tout piloter en microservices, ni en mainframe ! L’API doit aussi durer un certain temps, parce que c’est un contrat entre un fournisseur de données/services et celui qui les consomme. Chacun doit pouvoir connaître la durée de vie de ce contrat. La grande question que pose l’automatisation, c’est de déterminer comment on équilibre court terme, moyen et long terme. Désautomatiser, c’est concevoir une stratégie, s’y tenir, tout en ayant une partie d’infrastructure prête à changer rapidement pour suivre l’évolution du marché. Ce n’est pas simple, mais c’est à ça que servent les conférences comme TIAD et API Days.

Est-ce qu’il y a un outillage particulier pour les API ?

Nous avons publié API landscape, qui recense plus de 100 compagnies qui fournissent des outils pour concevoir, designer, documenter, manager ou intégrer les API, mais il y a aussi beaucoup d’open source. Parmi les tendances du moment, une stack se dégage : Swagger, qui s’appelle maintenant Open API Initiative, est un framework de description d’API. C’est lisible par les machines, et facile à écrire pour les humains! Une fois qu’on décrit son API dans format OAI, on peut générer des outils automatiques : de la documentation, des portails développeurs, des process de CI/CD, des tests, des SDK dans une dizaine de langages. De nombreuses autres plateformes existent. Mais aujourd’hui le coeur du mouvement, c’est la définition d’API, et OAI en particulier. Il en existe aussi d’autres comme API Blueprint et RAML.

API Landscape – Voir lien plus haut pour le fichier haute résolution

Pour terminer, quels sont les prochains défis à relever ?

Aujourd’hui nous allons vers l’IoT, et les API sont appelées à communiquer avec des objets multiples. Cela suppose d’avoir une logique multi-channels pour pouvoir adresser tous les objets, plusieurs marchés, avec une seule plateforme. Il y a de forts enjeux derrière tout cela : une voiture connectée, c’est un smartphone d’une tonne qui roule à 120 km/h ! D’où l’importance de la désautomatisation lors des phases de design et de conception. Et puis il faut réfléchir à la place de la donnée dans notre monde. En 2008, Chris Andersen écrivait sur la fin de la théorie, ou quand les nouveaux outils (Google, Twitter) permettent d’extraire des données en temps réel et mieux prévoir l’avenir (une épidémie de grippe, par exemple) que des modèles scientifiques. Quand la donnée amène plus de savoir que la science, il est indispensable de confier cette donnée à des gens qui réfléchissent à ce qu’ils en font. Parfois, pour pouvoir comprendre la mécanique à automatiser, il faut plonger les mains dans le cambouis et refaire la tâche manuellement, pour l’automatiser de la bonne manière. On ne doit pas en arriver à la Datacratie, au point où c’est la donnée qui gouverne. La donnée est censée appuyer, aider, confirmer l’intelligence humaine, pas l’inverse. Comme l’a écrit Sénèque :

Il n’est pas de vent favorable pour celui qui ne sait où il va

Pour rester informé de l’actualité des API et de l’automatisation, inscrivez-vous à la newsletter du TIAD :