Atomiser son Système d’Information

S’il y a un des mérites qu’il faut reconnaitre à la mode des architecture RESTful c’est bien celui d’avoir rappelé cette évidence : HTTP est un protocole applicatif, et donc que le web est une application.

Et à qui me demande aujourd’hui « qu’est ce que REST ? », je réponds simplement que c’est d’abord un principe d’architecture dans lequel les données et les informations ont des adresses (URI), ce qui est déjà énorme quand on doit traiter des problématiques d’accès à l’information et d’interopérabilité entre des systèmes d »informations. On peut donc faire beaucoup de choses dans un système d’information en considérant HTTP comme un véritable protocole applicatif, et pas seulement comme un protocole de transport.

Dans une architecture RESTful, la plupart des échanges via les APIs se font en utilisant des messages XML. On peut donc construire des Architectures RESTful pourvu que des APIs soient RESTful, c’est à dire qu’elles respectent un certain nombre de principes. On peut même enrichir la démarche en s’appuyant à la fois sur un vocabulaires XML, c’est que l’on fait en utilisant le vocabulaire XML ATOM, et en utilisant un protocole applicatif qui s’appuie sur – et respecte – HTTP, c’est ce que fait le protocole de publication Atom (ATOMPUB). Ainsi, au dessus de HTTP/XML on peut utilsier ATOMPUB/ATOM, tout en respectant les principes REST.

ATOMPUB permet de :

• constituer des collections : c’est à dire de constituer un ensemble de ressources, qui peuvent ensuite être récupérées en entier ou en partie ;
• offrir des services : pour découvrir et décrire des collections ;
• éditer : pour créer, modifier et supprimer des ressources.

De fait, ATOM est largement connu en tant que vocabulaire XML, puisque c’est celui qui est utilisé pour restituer les publications des blogs sous forme de fils ( feeds) auxquels on peut s’abonner.

Ce qu’apporte le protocole ATOMPUB, c’est une certaine façon de considérer – voire de reconsidérer – les stratégies d’intégration et d’inter-opérabilité au sein d’un système d’information. En l’occurrence, la stratégie repose sur un protocole universel de cataloguage temporel des ressources du système d’information, puisque le vocabulaire ATOM  permet de proposer des agrégations de ressources associées à des métadonnées dont une est le timestamp, une étiquette temporelle. Cette dernière autorisant une vision de l’ensemble des ressources de l’entreprise selon leur date de mise à jour et en fonction de qui a fait cette mise-à-jour. Je me permets de souligner le terme de cataloguage, car cela induit mécaniquement une vision documentaire du système d’information.
Ce que je suis en train de décrire, n’est rien d’autre que la panacée pour un moteur de recherche qui doit pouvoir collecter aisément des ressources structurées selon une vision informationnelle et documentaire des données du système d’information, et ceci au moins à triple titre :

• D’abord parce que les ressources sont exposées, elles ont une URI ;
• Ensuite parce que les APIs étant RESTFul elles doivent respecter le principe « d’hypermedia en tant que moteur de l’état des applications » qui facilite le travail du crawler du moteur de recherche ;
• Enfin parce que les métadonnées de collection et d’étiquette temporelle permettent à la fois de faciliter l’indexation incrémentale des ressources ainsi que la restitution structurée des réponses.

Dans la configuration ou les applications offrent des APIs ATOMPUB, chacun comprendra que la stratégie de moteur de recherche dans le système d’information prend une toute autre dimension.

Avec la mise en place d’APIs ATOMPUB RESTful, il s’agit ni plus ni moins que de proposer un fil de news universel du système d’information qui peut donc être utilisé pour la consultation ( notamment via le moteur de recherche ou via des lecteurs de flux ATOM), mais également pour l’écriture et la modification des ressources (et c’est là que les vertus d’intégration et d’interopérabilité d’ATOMPUB s’expriment).

Pour la partie implémentation technique on peut utiliser des framework comme Snaplogic , Twinsoft (pour les mainframe), Kapov, etc. Voire même utiliser un serveur ATOM grâce à AtomServer, qui utilise Abdera, le projet Apache d’implémentation du protocole AtomPub.

Pour ceux qui se disent « mais cela ressemble à WebDav, non ?  » je reprends les propos de Tim Bray qui précise que :

AtomPub is different from DAV in two key respects:

• The client doesn’t control where things go, the server does;
• It is allowed and expected that an AtomPub server will look at the incoming information and change it (generate ID, timestamps, sanitize HTML, etc.

Maintenant, si vous vous posez la question de savoir quand est-il intéressant de mettre en place une architecture ATOMPUB, je pense qu’il faut simplement regarder du côté du vocabulaire XML qu’est ATOM : si les données manipulées ont des titres, des auteurs, des localisations et des dates de mise à jour, alors vous avez votre réponse.