Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

Nous en parlions précédemment : en dépit du fort potentiel qu’ont les APIs Semantic REST, toutes les idées que nous vous avons partagé au cours de cette enquête sont soit des prototypes de recherche, soit nos propres visions.

Rassurons-nous, comme nous l’avons vu, il est bien possible de développer des APIs Semantic REST dès aujourd’hui. Cela constitue toutefois avant tout un pari sur l’avenir (quoi que le challenge intellectuel est lui aussi un bon candidat) et les standards qui mettront tout le monde d’accord sont toujours attendus.

Pourquoi un pari sur l’avenir ? Et bien tout simplement parce que les articles, tutoriels et cours qui expliquent ce concept sont encore rares. Et les outils production-ready qui tirent parti de la richesse de ces APIs n’existent pas encore. De plus, implémenter ces APIs nécessite de développer des fonctionnalités qui devront à terme être supportées nativement par les frameworks.

Au travers de cet article, nous vous partageons notre vision des challenges à adresser pour faire tendre ce domaine davantage du côté “must-have, facile à produire” que de celui des projets de recherche.

1. Faciliter la production d’APIs Semantic REST

Aujourd’hui, produire une API REST documentée avec Swagger est devenu rapide grâce aux frameworks comme Express, Django, Symfony, Spring ou Play!, et aux clients REST qui aident les développeurs à les tester manuellement, comme Postman et Insomnia.

Lorsqu’il s’agit de produire une API Semantic REST, il n’existe qu’un seul framework qui rend la tâche rapide : API Platform, basé sur PHP. Du côté des clients REST, aucun ne supporte ces nouvelles possibilités.

Que manque-t-il donc à ces technologies pour nous aider à développer des APIs Semantic REST ?

Frameworks

Du côté des frameworks, pour faciliter la création d’API Semantic REST, ils leur manque la possibilité de :

• permettre au développeur de modéliser les contraintes métiers, résolues à partir des contextes de la ressource et de la requête, qui régissent la disponibilité de chaque opération sur une ressource;
• générer la description des contrôles hypermedia disponibles sur la ressource retournée en réponse à la requête du client;
• utiliser des vocabulaires sémantiques pour documenter l’API (Swagger ne l’est pas);
• permettre au développeur de décrire la sémantique des modèles de données et opérations qu’il expose, par exemple avec des annotations sur les classes et attributs ;
• supporter les formats de documents hypermedia et RDF;
• exprimer les liens entre les ressources.

Ces fonctionnalités pourraient être implémentées par défaut dans les frameworks, être proposées par des développeurs tiers comme plugin du framework ou même sous la forme d’une librairie tierce. Toute entreprise ou développeur peut donc contribuer à réduire cette liste.

Clients REST

A l’inverse des frameworks, les clients REST n’aident pas directement le développeur à écrire le code qui rendra l’API fonctionnelle. En revanche, ils l’aident à tester si l’API en cours de développement fonctionne correctement. C’est un outil qui est très utile au développeur au quotidien.

C’est alors en exploitant les métadonnées exposées par l’API Semantic REST (principalement de la documentation), afin de simplifier et rendre plus facile la navigation de l’API par le développeur, qu’ils pourront l’aider dans son développement.

Les clients REST pourraient notamment :

• automatiquement générer des formulaires et requêtes HTTP pré-completées à partir des descriptions fournies par l’API lorsque l’utilisateur clique sur un contrôle hypermedia;
• présenter à l’utilisateur les définitions et les types des données, qui sont présents dans le vocabulaire RDF, pour le guider dans son interaction avec l’API.

2. Faciliter la consommation d’APIs Semantic REST

Les APIs REST, et Semantic REST sont toutes des APIs HTTP. Elles sont consommées par d’autres logiciels, écrits dans n’importe quel langage de programmation.

En tant que développeurs, nous utilisons des librairies de clients HTTP pour faire des requêtes aux APIs. Aujourd’hui, ces librairies n’exploitent pas les possibilités offertes par les APIs Semantic REST, elles exploitent soit l’hypermedia, soit la sémantique, mais jamais les deux. Les librairies supportant l’hypermedia peuvent être trouvées ici. Interagir avec le semantique Web nécessite deux librairies : une pour faire des requêtes SPARQL, une autre pour parcourir le graph RDF reçu en réponse. Cette dernière dépendra du format du document reçu.

Comme nous l’avons vu précédemment, ces APIs permettent de réduire le couplage clients-serveur à la sémantique des données et opérations manipulées. Cela grâce à la richesse et la technologie des métadonnées qu’elles fournissent. C’est un grand pas en avant vers des SI significativement plus flexibles, maintenables et évolutifs.

Pour les exploiter, les librairies de clients HTTP devront être enrichies de nouvelles capacités :

• suivre des contrôles hypermedia et automatiquement générer les requêtes HTTP permettant de les actionner;
• récupérer une valeur dans une réponse à une requête, ou choisir un contrôle hypermedia, à partir d’un ou plusieurs mots issus de vocabulaires RDF, plutôt qu’un mot-clé;
• déréférencer une ressource liée à celle qui vient d'être demandée.

L’un des enjeux de ces librairies est de proposer suffisamment de dictionnaires RDF pour que l’utilisateur ait rarement à aller en chercher par lui même, ainsi que faciliter l'écriture de la recherche de contrôles hypermedia ou données dans une réponse.

3. Construire un écosystème d’outils utiles (et fun) autour des APIs Semantic REST

Lorsque nous aurons la capacité de créer et consommer ces APIs facilement, il deviendra possible de laisser libre cours à notre imagination pour créer de nouveaux outils, et ainsi voir émerger un écosystème riche, comme l’est celui des APIs RESTful aujourd’hui.

Dans cette partie, nous vous partageons nos idées, classées dans l’ordre dans lequel nous aimerions les voir apparaître.

1 - Des interfaces visuelles qui se génèrent automatiquement

Nous vous présentions cet exemple dans notre article Hypermedia et sémantique dans les APIs : un mix puissant.

Un tel outil permettra aux profils non-techniques de présenter et tester n’importe quelle API Semantic REST. Il ne serait plus nécessaire de développer des interfaces graphiques, spécifiques à une API, dédiées à faire des démonstrations.

Nous pensons qu’un tel outil apporterait beaucoup de valeur à l'écosystème des APIs Semantic REST car il les rendrait plus accessibles que les APIs RESTful.

2 - Des outils de tests fonctionnels et de charge automatisés

Une fois de plus nous vous présentions cet exemple dans notre article Hypermedia et sémantique dans les APIs : un mix puissant.

La mise en place de ces tests est chronophage et souvent continuellement repoussée à plus tard. Avoir des outils qui les génèrent automatiquement ferait gagner du temps aux équipes de développement et leur permettrait d’obtenir davantage d’information sur le fonctionnement des APIs développées, ce qui permet de prendre de meilleures décisions.

Nous pensons qu’il s’agit d’un type d’outil qui augmenterait la valeur perçue des APIs Semantic REST.

3 - Des clients HTTP capables de remplacer automatiquement une API par une autre qui répond aussi au besoin

Lorsque l’on souhaite récupérer la météo en un lieu, ou l’adresse d’un magasin, pourquoi utiliser une API bien précise ? Ne serait-ce pas plus intéressant pour les utilisateurs de toujours utiliser l’API la plus fiable et qui répond le plus vite ?

Avec la sémantique, nous pourrions lui décrire l’information recherchée et cette librairie s’occuperait de trouver et d'intégrer l’API qui correspond le mieux à notre besoin, en la remplaçant par une autre dès que nécessaire.

Cet outil nécessite toutefois la mise en place d’un registre centralisant les descriptions et évaluations des APIs Semantic REST disponibles sur le Web.

4 - Des logiciels capables de découvrir les scénarios d’usage d’une API

Au fur et à mesure que le nombre d'opérations HTTP proposées par une API augmente, il devient de plus en plus difficile d’identifier comment l’utiliser et quelles opérations peuvent être composées.

La richesse des APIs Semantic REST nous permet de créer des agents logiciels capables de découvrir et présenter les scénarios d’usage d’une API. Cela rendrait les APIs plus facile d'accès.

5 - Générateur de documentation statique

Un framework permettant de créer des APIs Semantic REST sera capable d’automatiquement documenter les modèles de données, opérations et liens entre les ressources. Il pourra de plus récupérer la description sémantique de tous ces éléments. Cette dernière contient régulièrement des définitions écrites pour l’humain.

A partir de cela, il devient possible de générer une documentation, et même sous la forme d’un site web, qui est plus riche qu’une documentation Swagger aujourd’hui, et dont les descriptions ont ete generees. Les développeurs n’auraient plus besoin d'écrire la documentation de l’API. De plus, en étant générée, il nous est garanti qu’elle sera a jour.

6 - Middleware créant automatiquement une API qui est l'agrégation de toutes les APIs du SI

La décomposition d’un SI en micro-services induit une complexité : il devient régulièrement nécessaire d’interroger plusieurs services pour réaliser un processus métier complexe. Deux solutions sont communes : créer une autre API dont c’est le rôle, ou orchestrer plusieurs requêtes depuis le client.

Les APIs Semantic REST permettent de créer un middleware qui génère automatiquement une nouvelle API REST ou GraphQL par dessus toutes celles composant le SI. Ce middleware n’a besoin que de la liste des IPs des services du SI et d’un mécanisme lui permettant d’obtenir leur documentation statique.

Challenges transversaux

Pour pouvoir créer ou améliorer ces outils présentés tout au long de l’article, il est nécessaire qu’un ou quelques formats de documents deviennent des standards, comme JSON l’est pour les APIs RESTful. Il en va de même avec les vocabulaire RDF.

Aujourd’hui, il existe de nombreux formats que nous classifions précédemment mais aucun ne fait l'unanimité. C’est un problème pour les créateurs d’outils. Le premier challenge de ce domaine est donc de faire émerger un standard.

Ensuite, si l’on veut tendre vers un monde dans lequel les APIs sont facilement remplaçables, nous aurons besoin d’un registre centralisant la description des APIs Semantic REST. De plus, afin de les sélectionner, il faudra pouvoir les évaluer en minimisant les interventions humaines et rendre cette évaluation interprétable par la machine. Voici deux challenges supplémentaires.

Pour finir, le dernier challenge que nous voyons est celui de rendre ces sujets plus accessibles. Notamment au travers d’articles, tutoriels et cours. Cela ainsi que populariser le domaine.

Conclusion

Pour fermer cette série, nous vous avons présenté les challenges et outils qui, nous le pensons, diminuerons le coût de produire des APIs Semantic REST et augmenterons leur valeur. Cela notamment grâce au couplage clients-serveur drastiquement réduit. Rappelons-le, d'après les professionnels du SI que nous avons interrogés, ce couplage est le principal problème technique du SI.

En résumé, nous pensons qu’il est nécessaire de simplifier la création de ces APIs, puis leur consommation. Et enfin, profiter de cela pour créer de nouveaux outils qui accélèreront les équipes de développement et rendront les APIs plus accessibles et le SI plus flexible. Au delà de ça, davantage de ressources pédagogiques seront nécessaires.

Ce dernier paragraphe clôt donc cette série sur les APIs Semantic REST. Nous espérons qu’elle vous aura été instructive, utile et que vous aurez autant apprécié la lire que nous l’écrire.