Dans un modèle client-serveur, un client est dit fortement couplé à un serveur lorsque son code contient des détails bien spécifiques au serveur à joindre : nom et adresse des opérations, modèles de données, règles métier et technologies.

Le client doit donc savoir à l’avance quoi faire (métier) et comment (technique).

À l’inverse, il est dit faiblement couplé lorsqu’il doit savoir en avance quoi faire, mais pas comment. Il déterminera cela au moment venu, grâce aux informations que lui communiquera le serveur.

Les APIs Web : un levier d’innovation et de business

Mais alors en quoi cela est-il problématique ? Vecteur de rigidité technologique et fonctionnelle dans le SI, ce couplage impose une maintenance régulière et coûteuse du SI, et réduit le rythme des nouveaux développements. Time-to-market et capacité à innover en sont les premiers affectés.

Parmi les moyens d’adresser cette problématique, les APIs sont particulièrement intéressantes.

Les APIs ont déjà montré leur propension à valoriser un SI. En ouvrant l’accès à leur plateforme, Slack et Twitter en ont fait un moyen de renforcer leur écosystème; Google a fait de son API de cartographie une importante source de revenus; SNCF a ainsi noué de nouveaux partenariats, augmentant ses ventes et améliorant son service; et enfin Stripe en a même fait son unique moyen de distribution.

Vers un SI plus intelligent et moins coûteux

Le business et le rayonnement engendrés par les APIs ne sont plus à prouver, mais cela à un coût. Malgré une première étape qui réduit le couplage technique existant – en passant de RMI, SOAP ou CORBA à RESTful – les clients d’API restent développés sur la base d’une documentation (Swagger) non-contextuelle et versionnée. Elle force le couplage aux modèles de données, règles métiers et URLs.

Alors comment faire pour continuer à réduire le coût, financier et technique, des APIs ?

En enrichissant les APIs de deux types de métadonnées : Hypermedia et Sémantique, ce qui les qualifie de “Semantic REST”.

Hypermedia ? Des métadonnées représentants des liens vers d’autres documents ou services accessibles sur le web (HATEOAS).

Sémantique ? Le sens des termes métiers utilisés, définis avec une technologie qui permet à la machine de les interpréter (OWL).

En exploitant ces métadonnées, les clients d’API pourront replacer le métier au coeur de leur code ! Composants visuels et formulaires seront générés en fonction de ce que fournit et attend l’API. Assistants intelligents et chatbots seront capables d’interroger de nouvelles APIs sans avoir été programmés spécifiquement pour.

Encore mieux, une API pourra être remplacée automatiquement par une autre, qui fournit le même service métier tout en étant plus performante.

Le résultat d’avoir de telles APIs, c’est qu’il n’est plus nécessaire d’implémenter les détails techniques, ni de les maintenir. Seul un changement du métier, ou de l’UI, entraîne un changement du client. En d’autres termes : quasiment plus de couplage technique (juste la technologie de description sémantique).

Ce nouveau style d’API est né de travaux de recherche. Il se rapproche de plus en plus de la réalité opérationnelle en offrant une solution au besoin d’un couplage réduit dans le SI moderne.

Il est temps pour la DSI de se saisir de ces technologies, elles lui permettront de prendre une longueur d’avance.