Tentative de définition d'une API par Spark Archives

Pas de solution logicielle aujourd'hui sans API ! Pas de mystère, les API sont aujourd'hui indispensables à tout le monde. Développeurs, architectes des SI, intégrateurs, clients,...

Mais qu'est-ce qui se cache derrière ce sigle ? Wikipedia en donne une définition :

En informatique, une interface de programmation applicative (souvent désignée par le terme API pour Application Programming Interface) est un ensemble normalisé de classes, de méthodes ou de fonctions qui sert de façade par laquelle un logiciel offre des services à d'autres logiciels. Elle est offerte par une bibliothèque logicielle ou un service web, le plus souvent accompagnée d'une description qui spécifie comment des programmes consommateurs peuvent se servir des fonctionnalités du programme fournisseur.

Une API, c'est donc à la fois un moyen technique, et une offre de service, qu'un logiciel (au sens large) propose. Ce service peut être purement interne (on parle d'API privée) ou exposées (on parle alors d'API publique). Une API publique se doit d'être documentée, que ce soit pour indiquer les services offerts, les formats de messages d'entrée et les formats des réponses,... Cette documentation permet l'exploitation de cette API par une équipe n'ayant aucun contact avec l'équipe ayant développé cette API.

Bien qu'un grand nombre de solutions techniques existent pour mettre à disposition des services, la méthode aujourd'hui dominante consiste à utiliser des WebServices. On entendra donc régulièrement (par extension) parler d'API Webservices, voire simplement de Webservices. Simplement, il s'agit d'utiliser un cadre technique d'échange qui s'appuie sur le protocole de transport HTTP.

Webservices: REST ?

Hier, les API webservices étaient un monde complexe, celui de SOAP et RPC. Aujourd'hui, REST est omniprésent. Mais c'est quoi REST ? REST est acronyme signifiant Representational State Transfer. Dit comme ça, on n'a pas beaucoup avancé... Plus sérieusement, REST est (pour la partie qui nous intéresse) un ensemble de contraintes et un style permettant de décrire des ressources (qu'on peut plus ou moins assimiler à des données):

1. Client-serveur;
2. Pas de gestion d'état coté serveur;
3. Mise en cache coté client des informations envisageable via des informations de durée de validité de l'information;
4. Hiérarchisation des services par couche;
5. Une interface uniformisée (essentiellement via des URI);
6. Utilisation des méthodes standards HTTP (PUT, GET,...) ainsi que des messages de retours (code) et des en-têtes HTTP.

Par contre, REST n'est pas à proprement parler une norme, mais s'appuie généralement sur un ensemble de normes (HTTP, URI, Json, XML,...). Au delà de la documentation, nécessaire comme nous l'avons vu pour une API publique, c'est bien l'adoption d'un style et d'un ensemble de contraintes communs qui fait le succès de REST. Leur simplicité et leur classicisme est un gage de réutilisation, ce qui est le propre d'une bonne API.

Et coté Spark Archives, on peut faire quoi avec ces API ?

Et bien il est possible de gérer un certain nombre de ressources via les API Webservices REST de Spark Archives:

• archives, versement, demandes, métadonnées riches,..

et d'agir sur ces ressources:

• verser des archives électroniques,
• rechercher dans les archives connues,
• créer des demandes, 
• et télécharger des archives électroniques,
• modifier des patients (métadonnée riche dans un contexte d'archives hospitalières)
• ...

Ces API sont bien évidemment documentées et versionnées. Elles sont régulièrement enrichies lors de nouvelles versions. Elles permettent dès aujourd'hui d'intégrer Spark Archives dans des contextes SI variés, et de simplifier le développement de connecteurs depuis des applications métiers.

Aujourd'hui, l'univers du Web modifie en profondeur les architectures logicielles. La mise à disposition d'API (publiques) est de plus en plus une brique technique indispensable, et le monde de la gestion des archives n'y échappe pas. Particulièrement, la tendance lourde à la dématérialisation des documents rend indispensable la communication d'application à application.

Spark Archives a fait le choix des webservices REST !

Jérôme BESNARD
Directeur R&D Spark Archives

Crédit photo : kirillm / 123RF Banque d'images

Crédit Wikipedia : Contenu soumis à la licence CC-BY-SA. Source : Article Interface de programmation de Wikipédia en français (auteurs