1. PLONGEE AU CŒUR DES NOTIONS
1.3. Identifier numériquement, dans quel contexte et pour quel
1.3.1. L’architecture REST et les API
Le Representational State Transfer, ou REST, est un style d’architecture pour les systèmes d’information. Il est créé en 2000 par Roy Fielding et comporte des prérequis applicables sur le web. Fielding était assez connu déjà de par son implication dans le développement du web, notamment http. On nomme RESTful les systèmes qui fonctionnent selon ce type d’architecture. Le principe, dans un contexte web, est d’utiliser systématique le protocole http ainsi que les URI comme identifiants, ce qui permet d’avoir « un système universel d’identification des
éléments de l’application »103. Chaque ressource est identifiée de manière unique.
La transparence des processus et la simplicité de leur fonctionnement est le maître - mot du REST : si une représentation est encodée en UTF-8, cela doit être explicite. Les ressources ont des représentations bien définies, et leur manipulation se fait via celles-ci.104
L’implémentation* du REST est en outre facile à mettre en place : il y a un très faible coût pour l’application, puisque l’on ne va pas « développer » spécifiquement une application pour ce service ; la maintenance en est facilitée ; côté client le développement et la maintenance sont faibles également, ce qui de manière globale garantit une facilité d’adoption très intéressante pour les structures culturelles qui souhaitent publier leurs jeux de données en ligne.
Une architecture en REST permet d’accéder à un document dans toutes ses représentations via un seul identifiant majeur identifiant la ressource en tant que concept : c’est ce qu’on appelle la négociation de contenu*.
« Beaucoup de gens ne savent pas que les URL n’identifient pas des fichiers mais des ressources. Cette conception amène la croyance erronée que l’accès html est forcément différent de l’accès aux versions en JSON et en RDF. »105
Concrètement, cela oblige à attribuer plusieurs URI : une pour la ressource, qui est générale et qui identifie le concept, l’entité, et une pour chacune des représentations de cette entité (RDF, JSON, HTML, etc.). Cela nécessite un développement « par le bas » (bottom-up) : partir de l’application finale désirée et du besoin pour créer un « hub » de métadonnées qui va permettre le lien entre les différentes URI créées.106
La négociation de contenu
Certains navigateurs gèrent le RDF et le html et indiquent leurs préférences dans leur header, plus spécifiquement dans la partie « accept » (par exemple Mozilla
103Representational State Transfer. Site Wikipédia [en ligne] Disponible sur
https://fr.wikipedia.org/wiki/Representational_state_transfer [consulté le 17/07/2017] 104 Ibid.
105 VAN HOOLAND, Seth. VERBORGH, Ruben. Op. Cit.
avec son extension Tabulator)107. Ainsi, la négociation de contenu fonctionne selon
les préférences indiquées dans les requêtes: le serveur de contenu va récupérer cette information lors de la première requête afin de pouvoir s’adapter au contexte et, grâce à cette information, fournir une représentation en HTML si c’est un utilisateur qui le demande via son navigateur, ou fournir un flux encodé suivant une des sérialisation de RDF si c’est une machine qui le demande en spécifiant explicitement ce format.108
La préférence pour un format ou pour un autre est indiquée par une valeur, « q », plus elle est élevée plus elle influe sur le choix.109 Le choix est donc plus
« fin », si la page HTML est simplement une copie bas de gamme alors le serveur renverra le RDF (sauf en cas de préférence explicite du client) ; inversement, si le RDF n’est pas complet ou vient directement du HTML, alors le serveur renverra la représentation en HTML (sauf, là encore, en cas de préférence du client).110
Une fois la requête reçue, le serveur redirige le client vers une URL où se trouve la représentation correcte. Cette redirection a pour nom de statut code 302
Found. Le client envoie alors une nouvelle requête http au serveur de la nouvelle
URL qui donne cette fois accès à la ressource dans la représentation souhaitée.111 Les API
Les Application Programming Interface (API) ou Interfaces de
programmation applicative sont des interfaces à travers lesquelles un fournisseur de
contenu offre un service à d’autres applications/logiciels. Le principe des API dans notre cas particulier est donc de déployer une interface entre le navigateur de l’utilisateur et la ressource, et ce, afin de récupérer les requêtes et redistribuer lui- même en fonction de la demande la version RDF, HTML, ou JSON d’un document. « Une API branchée sur une base de données fonctionne donc de la manière
suivante : vous lui fournissez une URL contenant un ou plusieurs paramètres ; elle vous renvoie un fichier structuré (XML ou JSON) avec une ou plusieurs réponses. »112
Dans le cas d’une architecture REST, l’API utilisée pour toutes les représentations dédiée à l’appréhension humaine est toujours le navigateur. D’autres fournisseurs de contenus préfèrent développer eux-mêmes une API qui va « aiguiller » les utilisations faites et restreindre en termes d’accès à certaines ressources, parfois en proposant à l’utilisateur de s’identifier avec un compte et un mot de passe113.
107 AYERS, Danny, VÖLKEL, Max. Op. Cit.
108 BERMЀS, Emmanuelle, ISAAC, Antoine, POUPEAU, Gautier. Op. Cit.
109 Par exemple, une préférence pour le html pourra être exprimée telle que html q=1.0 et RDF q=0.7. 110 AYERS, Danny, VÖLKEL, Max. Op. Cit.
111 Ministère de la Culture et de la Communication. Op. Cit.
112 CAVALIE, Etienne. Utiliser les SPARQL Endpoint comme si c’était des API. Site Bibliotheques.wordpress.com, 2012. [En ligne] Disponible sur https://bibliotheques.wordpress.com/2012/11/22/utiliser -les-sparql-endpoint-comme-si- cetait-des-api/ [consulté le 17/07/2017]
C’est le cas notamment de la Digital Public
Library of Australia (DPLA) qui n’est pas structurée
en REST, et qui propose en outre une partie de ses ressources en libre accès en HTML. Si l’on souhaite accéder à la version JSON de celles-ci, il faut s’enregistrer pour accéder à l’API DPLA spécifique. Cela demande en sus une procédure longue et fastidieuse nécessitant de trouver la syntaxe exacte des demandes en JSON dans leur documentation, puisque c’est une API qui leur est propre, et ensuite trouver l’URL spécifique de l’objet que l’on recherche en particulier à partir de l’URL en HTML, etc. Tout cela doit se faire manuellement et individuellement pour chacune des ressources, ce qui limite le moissonnage automatique et la réutilisation des données. De plus, on voit bien que connaître le fonctionnement de l’API dédiée d’une certaine base de données, (ici, celle de la DPLA) ne donne pas un savoir universel sur toutes les autres bases de données que l’on pourrait utiliser. Chacune est façonnée sel on son propre modèle et cela participe au cloisonnement des informations.114
Europeana fait également partie de ces fournisseurs de contenu qui fonctionnent avec une API personnalisée, mais celle-ci est en REST et Open-Source. Elle vient d’ailleurs tout juste d’être récompensée du prix de l’API gagnante dans la catégorie des API de données, du prestigieux évènement API World 2017 ayant lieu dans la Silicon Valley en Calfiornie115. Le fondateur de l’évènement, Geoff Domoracki, déclare que « L’API REST d’Europeana est un merveilleux exemple
montrant comment l’industrie technologique réalise de plus en plus que les API ne sont pas juste une manière d’intégrer des outils et des applications, mais qu’elles sont la nouvelle façon de faire du commerce et de créer des n ouvelles technologies révolutionnaires. »116
Que choisir ?
Les systèmes qui ne sont pas construit en REST font face à certaines difficultés, notamment le fait que les identifiants de chaque représentation d’une même ressource ne soient pas liés à un identifiant « maître », rendant l’interopérabilité difficile. Les URI identifient des représentations plutôt que des ressources, nous avons donc besoin d’être vigilants sur la construction de celles -ci. En outre, les URL JSON incluent souvent des informations sens ibles touchant au cœur du fonctionnement du système, conséquence de l’utilisation des URL non pas comme identifiants pour des ressources mais comme des instructions pour programme. On ne peut donc pas forcément les diffuser tels qu’elles. Inversement, les RESTful API ont des détracteurs de leur côté, qui estiment qu’elles ne sont pas la panacée en termes de fonctionnement technique (difficulté à « débuguer », le
114 VAN HOOLAND, Seth. VERBORGH, Ruben. Op. Cit.
115 Europeana REST API wins the 2017 Data APIs category award . Pro.europeana.eu [en ligne] Disponible sur
http://pro.europeana.eu/pressrelease/europeana-rest-api-wins-the-2017-data-apis-category-award [consulté le 16/08/2017] 116 Ibid. Concept API RDF HTML JSON URL
vocabulaire REST n’est pas assez riche pour une API, une confusion terminologique sur ce que veut vraiment dire une API en REST, etc.).117
D’autres types d’architectures permettent de gérer les données : l’architecture SOA (Service Oriented Architecture ou Architecture orientée services) est une architecture dont le but est d’établir des connexions entre les bases de données une à une. Cela repose sur l’alignement des processus et non des données. Cependant cela donne parfois lieu à des architectures informatiques complexes, difficiles à maintenir et peu évolutives.118 SOAP (Service Oriented Architecture Protocol) est à l’architecture SOA ce qu’http est à l’architecture REST : un protocole servant au transport et à la structuration des données. Il y a en outre d’autres types d’architectures plus spécifiques, notamment l’architecture Business Intelligence, intéressante dans le cas de données quantitatives pour les statistiques, les vues de données… au sein des entreprises notamment ; ou encore le Master Data
Management proposant une base pivot entre toutes les données.119 Cette diversité permet aux organisations d’adapter leurs systèmes à leurs besoins précis, même si les avantages et les inconvénients doivent être étudiés avec attention lors de l’implémentation et ne doivent pas entrer en contradiction avec les objectifs initiaux.