Suite à la demande d’un collègue (qui se reconnaitra), voici une petite explication rapide et technique de ce qu’est OData.
SQL, mais pour le web
Pour faire on ne peut plus court, OData est un protocole qui est l’équivalent pour le web de la norme SQL pour les bases de données. De la même manière que SQL est un langage qui permet de requêter de la donnée filtrée, triée, projetée, depuis un SGBD, OData est une syntaxe qui permet les mêmes opérations, mais sur des sources de données rendus disponibles par le biais du protocole HTTP.
Dans le cas d’une base de données, on utilise un client qui fournit la syntaxe au serveur, qui exécute la requête et renvoie les données. Dans le cas d’un service OData, le fonctionnement est absolument identique : le client (n’importe quel client web, comme un navigateur par exemple) envoie une requête suivant la syntaxe OData, et reçoit le résultat.
Ni standard, ni norme, mais un protocole
OData est un protocole, qui n’est pas encore normé. Microsoft est à l’origine de ce protocole fortement ressemblant à GData (que Google n’a jamais réussi à faire prendre par manque de serveurs et de clients l’utilisant), et l’a proposé à normalisation à l’Oasis si mes infos sont correctes.
En attendant, il se trouve un peu comme un standard de fait pour le requêtage et l’exposition de données sur les protocoles web. Bien sûr, les produits de Microsoft se basent dessus (les collections de SharePoint, les sources de PowerPivot, un plugin pour utiliser du OData dans Excel, des points d’exposition sur SQL Server, etc.) mais ce qui est intéressant est que d’autres s’y mettent aussi (IBM, SAP, e-Bay, etc.)
OData ≠ Open Data… mais il y a quand même un lien
OData est un protocole technique, tandis qu’Open Data est un mouvement politique prônant l’ouverture des données publiques sous une forme électronique, de façon à favoriser son appropriation par les citoyens, sa réutilisabilité dans l’économie, ainsi que la transparence générale de l’Etat et des administrations par rapport aux administrés.
Evidemment, le nommage n’est pas anodin, et la ressemblance est forte à dessein. Microsoft livre un framework OGDI en Open Source qui permet aux collectivités locales de mettre en place des services Open Data sur internet, typiquement sur Azure, le Cloud de Microsoft. Le Conseil Général de Saône et Loire a été le précurseur sur cette technologie. Et bien évidemment, le protocole d’exposition des données préférentiel d’OGDI est OData. Le besoin d’interopérabilité au niveau des données est réel pour que le mouvement Open Data puisse atteindre la taille critique et montrer ses bienfaits. OData veut se poser en protocole de référence pour cette interopérabilité des sources.
Un exemple
Une source OData bien connue est le catalogue d’informations sur les films NetFlix. Cette source est disponible sur l’URL suivante :
http://odata.netflix.com/v2/Catalog/
Si vous allez sur cette URL, vous obtiendrez l’affichage suivant :
Un service OData contient plusieurs collections de données qui ont un sens à être groupées, traditionnellement parce qu’elles ont des liens. Par exemple, dans notre cas, il y a un lien entre la collection des titres de films et la collection des genres associés. Du coup, on peut commencer par regarder la liste des films en rajoutant simplement Titles/ dans l’URL, ce qui donne l’affichage suivant :
Internet Explorer affiche de manière particulière le contenu car il s’agit d’un flux AtomPub, qu’il reconnait, mais si on regarde le source, voici ce qu’on trouve :
Plus de détails sur la sortie
Assez indigeste si on le regarde tel quel, mais si on s’attache au squelette, et qu’on met en valeur le plus important, c’est assez simple comme flux de données :
<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?>
<feed xmlns=”http://www.w3.org/2005/Atom”>
<title>Titles</title>
<id>http://odata.netflix.com/v2/Catalog/Titles/</id>
<updated>2013-03-12T22:26:53Z</updated>
<entry>
<id>http://odata.netflix.com/v2/Catalog/Titles(’13aly’)</id>
<title>Red Hot Chili Peppers: Funky Monks</title>
<summary>Lead singer Anthony Kiedis, bassist Flea, (…)</summary>
<link rel=”http://schemas.microsoft.com/ado/2007/08/dataservices/related/Genres” type=”application/atom+xml;type=feed” title=”Genres” href=”Titles(’13aly’)/Genres” />
<m:properties>
<d:AverageRating m:type=”Edm.Double”>3.3</d:AverageRating>
<d:ReleaseYear m:type=”Edm.Int32″>1991</d:ReleaseYear>
<d:TinyUrl>http://movi.es/13aly</d:TinyUrl>
</m:properties>
</entry>
<entry>
(…)
</entry>
Le format AtomPub est composé d’un élément racine feed, qui contient des éléments entry correspondant chacun à une ligne de données. Dans ces éléments entry, on trouve des valeurs standards comme l’id, le title, le summary, etc., mais aussi un élément m:properties qui contient des colonnes complémentaires.
L’élément link correspond à des relations possibles avec d’autres parties du flux OData. En l’occurrence, on a laissé dans l’exemple raccourci ci-dessus celui correspondant à la récupération du genre de la première entrée de donnée.
Si on utilise l’URL donnée comme identifiant de l’entrée exemple, on obtient ceci :
En pratique, il n’y a pas vraiment d’erreur, c’est juste qu’IE ne sait pas afficher une entrée AtomPub seule. C’est à peu près pareil dans Firefox, mais si on regarde ce qui est effectivement envoyé, on a bien le contenu de l’entrée unique qui nous intéresse :
Que peut-on faire de plus avec l’URL ?
Si on s’arrêtait là, ça serait déjà pas mal : on peut récupérer de la donnée à un format à peu près connu et standard sur internet. Mais pour mériter d’être comparé à SQL, il faut bien sûr plus. Commençons justement par la relation dont on parlait juste avant : retrouver les genres associés à un titre, typiquement celui qu’on avait affiché juste au dessus. Pour cela, nous suivons le lien proposé, à savoir http://odata.netflix.com/v2/Catalog/Titles(’13aly’)/Genres
Mauvaise pioche, ils ne sont pas renseignés, et on a donc une liste vide :
Par contre, si on regarde la liste des langues associées, il y a de la donnée :
Un petit détour par REST
Tant qu’on est là, autant parler de REST, pour expliquer rapidement pourquoi il y a un lien fort entre OData et REST, justement. Le principe de REST est de revenir aux fondamentaux du web, en utilisant les verbes HTTP pour accomplir des opérations de lecture ou de modification sur des ressources représentées par leur URL.
Dans notre cas, on a bien une représentation des ressources par l’URL, puisque les entrées ont un identifiant sous forme d’URL justement. De plus, la composition progressive des URL permet de naviguer dans la source de données, ce qui est typique d’un service REST : il doit être à découverte progressive, et utiliser les conventions les plus simples possibles pour naviguer. Dans notre cas, cela consistait à utiliser l’identifiant entre parenthèses, puis à rajouter le nom de la relation derrière pour arriver à la liste des langages pour un film donné.
Filtres, tri, etc.
Qu’est-ce qui nous manque de plus pour être l’équivalent de SQL en HTTP ? Quelques opérations comme le tri, la projection, les filtres… Pour ce qui est du tri, il y a l’opérateur $orderby. Il s’utilise comme ceci :
http://odata.netflix.com/v2/Catalog/Titles?$orderby=ReleaseYear
Il peut bien sûr prendre plusieurs colonnes, dont on ira chercher le nom dans les propriétés des entrées. De la même manière, il y a toute une grammaire pour réaliser des filtres, dont voici un exemple :
http://odata.netflix.com/v2/Catalog/Titles?$filter=startswith(Name,’A Tribute’)
Bien évidemment, il y a plein d’autres fonctions utilisables pour les filtres, qu’on peut trouver dans la documentation OData : substring, length, tolower, toupper, round, floor, ceiling, ainsi bien sûr que de nombreux opérateurs de comparaison et d’autres méthodes.
Et le contrat là-dedans ?
Pour trouver les colonnes sur lesquelles on peut travailler, on peut également utiliser le mot clé $metadata, qui va nous renvoyer une description du flux :
Evidemment, ceci contrevient aux conventions de REST, où on a normalement une approche exploratoire du service, en fournissant une structure au fur et à mesure qu’on l’utilise. Les métadonnées permettent d’explorer un service avant de l’appeler, ce qui n’est pas très REST, mais parfois bien pratique. Attention par contre à ne pas développer trop de code généré par rapport à ce schéma, car il y aurait alors couplage. Le mieux est de garder une certaine dynamicité.
OData pour qui ? pour quoi ?
En conclusion de cette très rapide introduction à OData, parlons un peu des usages…
OData pour les développeurs
Pour les développeurs, OData peut être vu comme un langage d’interrogation de sources de données distantes. De la même manière que SQL permet de requêter des données dans un SGBD-R, OData permet de requêter des données sur un point d’entrée HTTP, dans une approche REST, et avec un format de retour AtomPub dans la plupart des cas, mais qui peut également être JSON. OData peut être vu comme un protocole du même plan que SOAP.
OData pour les urbanistes
Pour un urbaniste, OData peut être un bon moyen de mettre en oeuvre du Master Data Management, et de mettre ainsi à disposition de tout son SI, ainsi que de l’extérieur, des sources de données uniques, qui serviront de référentiels pour tous les services.
OData pour les administrateurs système
Pour les administrateurs système, un service OData reste simple à mettre en place, car il s’agit dans la majorité des cas d’une simple application web, avec un point d’entrée HTTP sur le port 80, éventuellement du SSL sur le port 443, et dans quelques cas une authentification, même si OData est souvent utilisée pour de la donnée publique.
OData pour les analystes de données
Pour les analystes de données, OData est un nouveau type de source, au même titre que CSV, Access, SQL Server, Oracle, etc. Pour être plus précis, OData se situerait plutôt au niveau de ODBC, car il s’agit d’un protocole qui peut être le même quel que soit le backend. Du point de vue de la consommation, OData peut être lu dans Excel par un plugin dédié, dans PowerPivot, et de plus en plus dans des clients hors-Microsoft.
OData pour les citoyens
Enfin, et nous finissons par le plus important, le citoyen… OData est particulièrement indiqué pour résoudre le problème d’interopérabilité qui va de plus en plus se poser sur les portails Open Data. Ces sites de mise à disposition de la donnée publique commence à se multiplier, ce qui est une très bonne chose, mais ils restent pour l’instant beaucoup basés sur des données dans des formats peu standardisés, voire carrément propriétaires (beaucoup d’Excel sur http://data.gouv.fr, par exemple), et qui ne rendent pas simples l’exploitation des données.
OData peut répondre à ce besoin en normalisant le protocole d’interrogation et de partage des données, y compris pour la réagrégation entre les différents niveaux d’exposition. Les entités qui exposent ces données publiques en sont souvent les principales consommatrices, et tirent directement avantage de la normalisation. Leur communication avec les strates plus hautes ou plus basses, qui n’utilisent pas nécessairement les mêmes vocabulaires et connaissances, en tireront encore plus de bénéfice.
.
) :
. D’ici qu’il vienne bosser avec nous…