Tutoriel ElasticSearch - Apprenez à gérer vos bases de données en NoSQL avec ElasticSearch

Pour comprendre comment l'indexation et la recherche de contenu se passent dans ElasticSearch, il faut que vous compreniez l'ensemble des concepts clés qu'il met en œuvre et la relation qui existe entre ces concepts. ElasticSearch possède six concepts qu'il est fondamental de comprendre pour pouvoir l'utiliser efficacement : le nœud, le cluster, l'index, le type/mapping, le document, la partition (shard) et la réplique.

• Le nœud : en ElasticSearch, un nœud fait référence à une instance d'exécution du logiciel ElasticSearch. Autrement dit, c'est un processus applicatif qui est exécuté sur une machine. Une machine ou un serveur virtuel peut exécuter une ou plusieurs instances ou nœuds ElasticSearch en fonction de ses ressources. Les nœuds peuvent également s'exécuter sur un cluster de machines lorsqu'il y a besoin de la haute disponibilité ;
• Le cluster : un cluster ElasticSearch est un ensemble d'un ou plusieurs nœuds. Comme nous l'avons dit précédemment, un nœud fait référence à une instance d'ElasticSearch, par conséquent un cluster entier peut tourner sur une machine virtuelle. Le cluster fournit l'indexation collective et la distribution des requêtes de recherche à travers tous les nœuds du cluster ;
• L'index : dans la terminologie ElasticSearch, un index est un ensemble de documents JSON. Nous y reviendrons plus bas ;
• Le type : encore appelé Mapping, le type fait référence à un ensemble de documents qui partagent un ensemble de champs communs, présent dans le même index. Le Mapping est l'un des éléments qui distinguent d'ailleurs ElasticSearch d'Apache Solr. Là où Solr exige que tous les documents JSON aient la même structure, ElasticSearch les stocke en l'état, mais utilise le type pour les catégoriser. C'est pourquoi on dit qu'ElasticSearch est « sans schéma » ou « n'impose pas de schéma à priori ». Ainsi, ces expressions que vous allez sans doute rencontrer ne font aucunement référence au schéma dans le sens SGBDR du terme. Nous y reviendrons plus bas ;
• L'indice : c'est le container logique des types. Le concept d'indice introduit les notions d'index ElasticSearch et index Lucene. Nous y reviendrons plus bas ;
• Le document : c'est un ensemble de champs ou propriétés définis de façon spécifique dans le format JSON. Chaque document appartient à un type et réside dans un index. À chaque document est associé un identifiant unique appelé UID ;
• La partition : de sa traduction originale Shard, une partition est une partie de l'index. Les index sont horizontalement partitionnés en shards, tout comme les tables dans un SGBD sont partitionnées en lignes. En d'autres termes, les documents JSON sont partitionnés par objet (par champs) et ces partitions sont réparties dans les nœuds du cluster ElasticSearch. Chaque partition contient toutes les propriétés (champs) du document, mais moins d'objets JSON. La distribution des partitions dans le cluster fait distinguer la notion de partition primaire et partitions secondaires. Nous allons y revenir plus bas ;
• La réplique : les index et les partitions sont répliqués à travers les nœuds du cluster pour accroître la haute disponibilité des traitements en cas de panne. De plus, les répliques permettent de paralléliser les traitements de recherche de contenu dans le cluster, ce qui accroît la performance d'ElasticSearch.

Dans ElasticSearch, l'unité est le document. En d'autres termes, l'index dans ElasticSearch c'est l'ensemble des documents qui sont stockés dans le moteur. Les documents sont enregistrés au format JSON. La structure hiérarchique du format JSON permet à ElasticSearch d'indexer tout le contenu des documents. À titre de rappel, le contenu d'un document JSON est formellement organisé sous forme d'objets. Chaque objet est l'équivalent d'une ligne dans une table de base de données relationnelle. Les documents sont organisés en séries de propriétés, qui sont l'équivalent des colonnes dans le monde des bases de données relationnelles. La figure ci-après illustre un document JSON. Bien que basique, il est important de comprendre cette organisation, elle vous servira pour comprendre l'organisation des données dans ElasticSearch et la façon dont les requêtes de recherche y sont exécutées.

Vous pouvez voir que le document JSON mis en avant dans la figure ci-dessus possède deux objets (ou deux lignes), il possède plusieurs propriétés. Le premier objet a pour propriété firstName la valeur Juvénal, tandis que le deuxième objet pour la même propriété a pour valeur Julie. Ce document a pour caractéristique de posséder la même structure pour tous les objets (les propriétés sont les mêmes d'un objet à un autre). Cependant, dans la vraie vie, le schéma ou la structure de données des documents est rarement la même. Dans la recherche de contenu, l'un des problèmes majeurs que l'on rencontre est la variété des formats de fichiers et des structures des données, ce qui complexifie l'indexation des données sur ces fichiers. ElasticSearch se démarque sur ce point en supportant toute forme de structure JSON. En d'autres termes, ElasticSearch indexe nativement des documents JSON dont la structure n'est pas identique d'un objet à l'autre ou d'un document à l'autre. C'est l'un des points qui le différencie de son rival, Apache Solr, qui exige que tous les documents JSON aient la même structure. Comment ElasticSearch réussit-il à indexer du contenu sur les documents JSON dont la structure est différente ? En introduisant la notion de type ou de type de document. Certains préfèrent parler de Mapping de document pour désigner le type. Formellement, le typage de document consiste à regrouper les documents qui partagent les mêmes propriétés (champs) dans le même indice. ElasticSearch gère le stockage des données d'une façon logique (conceptuelle). Ainsi, l'indice est le container logique de l'ensemble des documents qui ont le même type, même si physiquement tous ces documents sont persistés au même endroit sur le disque dur. La notion d'indice permet d'introduire les concepts d'index ElasticSearch et index Lucene. Dans le point suivant, vous allez comprendre leur importance. L'index ElasticSearch ou index au sens ElasticSearch du terme, fait référence à l'ensemble des indices de l'index. L'index ElasticSearch est le container logique de l'ensemble des indices. Gardez toujours à l'esprit que l'index désigne simplement l'ensemble des documents JSON stockés sur le disque. Vous pouvez imaginer l'index ElasticSearch comme une base de données relationnelle et au sein de cette base de données, il y a plusieurs tables, chaque table regroupe l'ensemble des lignes qui possèdent les mêmes colonnes. Dans notre analogie, la base de données serait l'index ElasticSearch, tout comme une base de données n'est qu'une représentation logique du stockage des données, tel l'index ElasticSearch est un container logique des indices. Chaque table de la base de données serait un indice, et tout comme la table n'est qu'une abstraction logique de stockage, ainsi l'indice est le container logique des documents du même type. Chaque table est simplement un ensemble de lignes qui partagent les mêmes colonnes. Dans ElasticSearch, les colonnes seraient le type et chaque ligne correspondrait à un document. L'ensemble des documents qui partagent le même type. Tout comme la base de données est stockée physiquement sur le disque dur non pas sous forme de tables mais comme des fichiers, tel est l'index. L'index est l'ensemble des fichiers JSON stockés sur le disque dur sans aucune abstraction logique. Cette distinction est très importante, car les indices sont traités indépendamment les uns des autres lors des recherches. À cause de cela, on dit d'ElasticSearch qu'il est tenant(2). Le tableau suivant va vous aider à retenir l'organisation des données dans ElasticSearch.

Le type est donc le moyen de séparation des documents dans l'index en groupes logiques. Attention quand même, le type sépare les documents uniquement d'un point de vue logique. Physiquement, les documents appartiennent tous au même index et sont persistés au même endroit sur le disque dur. Tout comme un SGBDR peut supporter plus d'une base de données relationnelle, vous pouvez définir plusieurs index ElasticSearch. Par exemple, dans une instance de SQL Server, plusieurs bases de données peuvent être installées et gérées. Il en est de même avec ElasticSearch. Toute instance d'ElasticSearch peut gérer un ou plusieurs index ElasticSearch. Laissez-nous illustrer tout cela par un exemple. Supposons que nous avons une base de clients constituée de quatre documents JSON dans ElasticSearch. La figure suivante illustre la structure de notre index.

Structure de l'index ElasticSearch. Tous les documents forment l'index. Dans l'index, les documents sont regroupés par type. Tous les documents qui ont la même structure sont rangés dans le même type (donc dans le même indice).

Comme vous pouvez le voir dans la figure, l'index est l'ensemble des quatre documents. Il est composé des quatre documents JSON Clients1.json, Clients2.json, Clients3.json et Clients4.json. Cependant, les documents clients3.json et clients4.json n'ont pas la même structure que les fichiers clients1.json et clients2.json. Ils possèdent la propriété address en plus qui est elle-même constituée d'un autre objet contenant quatre propriétés (rue, ville, CodePostal et Pays) que nous avons surlignées dans la figure par le rectangle bleu ciel. Pour indexer ces deux documents, l'utilisateur doit obligatoirement spécifier leur type au moment de leur ajout dans le moteur ElasticSearch. Dans la partie suivante, nous allons vous montrer comment. Pour nos besoins, nous avons choisi de nommer ce type adresse. Le type adresse contiendra dans l'avenir tous les documents qui ont la même structure que les documents clients3.json et clients4.json. En créant ce type, ElasticSearch va indexer les quatre propriétés de la propriété address et l'utilisateur pourra effectuer des recherches qui pointent uniquement sur ces quatre propriétés dans l'ensemble des documents du type. Nous allons vous montrer comment dans la partie suivante. Les documents de type adresse sont placés dans l'indice 1. Les deux autres documents sont placés dans l'indice 2. En fait, tout document qui est ajouté dans ElasticSearch doit obligatoirement être placé dans un indice. L'ensemble de ces deux indices forme un index ElasticSearch. Les indices sont ensuite indexés indépendamment les uns des autres. Nous allons maintenant aborder l'architecture d'ElasticSearch et comment celle-ci s'harmonise avec cette organisation de documents.

L'approche conceptuelle utilisée par ElasticSearch pour l'indexation et la recherche de contenu conditionne son architecture tout entière. Lorsque vous installez ElasticSearch, vous l'installez par défaut sur une machine. Une instance d'ElasticSearch est démarrée sur cette machine. Cette instance s'appelle un nœud. À l'aide des techniques de virtualisation, vous pouvez démarrer plusieurs instances d'ElasticSearch sur la même machine. Vous pouvez également installer ElasticSearch sur un ensemble de machines configurées en cluster Maître/Esclaves. Dans les deux cas de figure, le cluster ElasticSearch n'est pas égal au nombre de machines ou machines virtuelles sur lesquelles est démarré ElasticSearch, mais à l'ensemble des instances d'ElasticSearch en cours d'exécution. Avec un cluster de nœuds, les activités de stockage, d'indexation et de recherche des documents sont distribuées à travers les nœuds du cluster. Voyons comment cela se fait.

Tout document qui arrive dans un cluster ElasticSearch est placé dans un indice et divisé en partitions (ou shards) selon la méthode round robin (Le SQL dans Hadoop : HiveQL et Pig). Ici, la méthode round robin assure que toutes les partitions auront à peu près la même taille. Les partitions représentent les documents JSON partitionnés en objets de taille à peu près égale. Les partitions sont l'équivalent des divisions des tables relationnelles en blocs de lignes selon une méthode de partitionnement. Le processus de partitionnement affecte également à chaque partition un identifiant. Par défaut, ElasticSearch partitionne les documents en trois partitions. Ces partitions sont ensuite répliquées entre les nœuds du cluster selon un facteur de réplication. Le facteur de réplication par défaut est de 5, en d'autres termes, chaque partition est répliquée 5 fois et ces 5 répliques sont réparties entre les nœuds du cluster. La réplication des données assure la haute disponibilité du cluster et garantit la continuité des traitements en cas de panne dans le cluster. Lors du processus de réplication, ElasticSearch désigne une réplique primaire pour chaque document. Si nous appliquons maintenant les concepts et les principes d'organisation de contenu que nous avons vus dans les deux points précédents, alors il apparaît que les répliques sont en réalité des blocs d'index. La recherche de contenu est faite sur les répliques et comme ElasticSearch est multi-tenant, chaque réplique est considérée comme un index en soi et traitée indépendamment. La figure suivante illustre l'architecture d'ElasticSearch.

La figure 10-3 met en évidence le fait que l'index (l'ensemble des documents) est divisé en trois partitions (pour chaque document de l'index) auxquelles sont affectés les ID 0, 1 et 2.  Attention, il faut comprendre que les partitions ne concernent pas un document, mais bien l'ensemble des documents JSON de l'index. La figure 10-4 suivante illustre parfaitement cela. Les partitions sont ensuite répliquées dans le cluster. La couleur violette foncée dans la figure 52 illustre la réplique primaire de chaque partition. C'est sur ces répliques primaires que les opérations d'indexation et de recherche sont faites avant d'être répercutées sur les autres répliques pour la prise de relai en cas de problème avec la réplique primaire.

Comme vous pouvez le constater, chaque partition est constituée d'un bloc de chaque document de l'index  et stockée sur le disque dur de la machine dans laquelle elle a été assignée. Les partitions sont individuellement indexées, ce qui permet de paralléliser ou de traiter de façon indépendante l'exécution des requêtes de recherche sur les nœuds ElasticSearch. Les partitions représentent des index de plus petite échelle (taille), plus simples  à traiter, comparer à l'index original. Vous retrouvez donc là les principes de fonctionnement de Hadoop : le gros fichier est découpé en blocs de petite taille et ces blocs sont traités individuellement par les nœuds du cluster, et ce de façon complètement tolérante aux pannes (Hadoop : la nouvelle infrastructure de gestion de données). ElasticSearch applique exactement le même principe avec les partitions. Techniquement, les partitions sont des index Lucene. Une instance d'Apache Lucene est affectée à chaque partition et ses répliques, et lorsque les requêtes des utilisateurs arrivent dans le système, chaque instance d'Apache Lucene effectue la recherche de contenu sur la partition à laquelle il a été affecté. Apache Lucene est un peu comme la fonction Map qui est attribuée à un bloc de fichier dans Hadoop. Apache Lucene transforme la partition en index inversé et c'est sur cet index inversé de la partition que la recherche de contenu est faite. À ce stade, vous avez compris comment l'indexation de contenu se passe dans ElasticSearch. Il est vraiment important de bien comprendre les principes que nous avons énoncés dans ces deux points si vous souhaitez maîtriser le développement d'application en ElasticSearch. Nous allons maintenant passer à l'étude de la recherche de contenu.

Avant d'entrer dans le vif du sujet, il faudrait d'abord aborder le fonctionnement du REST de façon générale et son rapport avec le JSON et le HTTP, car la compréhension de l'API REST d'ElasticSearch passe par la compréhension du REST. De plus, dans le développement d'applications en Big Data en général et sur Hadoop en particulier, vous rencontrerez et manierez beaucoup les API REST. Par contre, ce point n'est pas pour tout le monde, il est juste pour ceux qui n'ont pas la connaissance élémentaire sur le REST et le fonctionnement du Web de façon générale. Si vous n'êtes pas de ces personnes, alors vous pouvez directement passer au point suivant.

REST est l'acronyme de REpresentational State Transfer, il décrit un style d'architecture logicielle permettant de développer une application devant fonctionner dans une architecture client-serveur, comme c'est notamment le cas sur Internet. REST n'est pas un protocole, mais un standard, une façon de développer une application qui va communiquer dans un modèle distribué (client-serveur)(3). Il a été mis au point en 2000 par Roy Fielding pour faciliter la communication des applications sur Internet. Pour comprendre le standard REST, il est impératif de comprendre comment la communication se passe sur Internet.

V-A-1. Les principes de la communication sur Internet▲

Après la connaissance des principes de communication dans un environnement distribué et sur Internet en général, il vous faut comprendre clairement la notion de service pour être opérationnel avec les API REST. Il y a beaucoup de définitions de service sur le marché, spécialement sur la notion de service Web. Cependant, nous trouvons que ces définitions ne reviennent pas suffisamment en profondeur sur le pourquoi des approches orientées service. À cause de l'utilisation des services dans les applications distribuées et sur Hadoop, nous allons vraiment expliquer dans le détail la notion de service. ElasticSearch n'est pas la seule technologie qui s'appuie sur des approches orientées service telles que l'API REST, Hadoop possède des outils de coordination de service comme ZooKeeper (Tutoriel d'initiation à l'écosystème d'Hadoop), qui s'utilise exclusivement en mode service exposé via une API. Ce point sort de l'étude d'ElasticSearch, mais est un prérequis obligatoire pour son exploitation.

La notion de service dans les logiciels applicatifs vient d'une stratégie d'alignement du Système d'Information aux objectifs de l'entreprise appelée l'urbanisation. Pour une entreprise, urbaniser son système d'information consiste à l'organiser de façon à ce qu'il puisse absorber en continu les évolutions métiers (diversification des offres commerciales, commerce électronique, gestion de la relation client, nouveaux modes ou canaux de distribution, etc.), technologiques (changement de logiciel, nouvelles versions de logiciel) et organisationnelles (Regroupements et fusions, acquisitions, partenariats, réorganisation, externalisation, redéploiement des fonctions de back et front office, etc.) auxquelles fait face l'entreprise, et ce à moindre coût. Pour ce faire, certains auteurs (Longépé, Hermès, Saassoon) proposent de considérer l'activité de l'entreprise comme un processus de production global qui se déroule en mettant en œuvre des traitements répartis dans différentes « zones ». Ainsi, urbaniser son système d'information revient à le découper en zones interdépendantes.

Le Système d'Information traduit la façon dont une entreprise acquiert, stocke, traite et diffuse les données au sein de l'entreprise. Ce système a pour support le système informatique qui lui-même n'est que l'orchestration d'un ensemble de technologies. Ces technologies déterminent l'efficacité du Système d'Information et l'efficacité du Système d'information va déterminer la performance de l'entreprise. Étant donné que le système informatique est l'infrastructure du système d'information, le « zonage » du système d'information entraîne nécessairement un « zonage » équivalent du système informatique. Une zone a pour équivalence en logiciel applicatif un service. Ainsi, zoner son système informatique revient à le réorganiser sous forme de services interopérables. La démarche SOA est la démarche à suivre pour garantir cette interopérabilité des services. Le SOA (Services Oriented Architecture), littéralement Architecture Orientée Services, est une démarche d'urbanisation qui consiste à organiser l'architecture du système informatique d'une entreprise comme un ensemble services interopérables. Le SOA est fondamental lorsqu'on veut tirer meilleur profit des technologies.

Le principe d'urbanisation est le suivant : un fournisseur offre un service à un client qui le consomme dans une relation de confiance établie entre les deux parties. Le client utilise (consomme dans le jargon) le résultat offert par le service sans se soucier de savoir comment ce dernier est obtenu. La démarche SOA suit ce même principe. Le service est une action exécutée par un fournisseur (producteur dans le jargon) à l'attention d'un client (consommateur dans le jargon) selon un contrat. Le Client est simplement utilisateur du service, il utilise le service sans savoir comment il est implémenté. Le client peut être un logiciel, un programme ou un autre service, qui fait appel aux fonctionnalités d'un autre logiciel. Le logiciel qui fournit ses fonctionnalités représente le producteur, tandis que les fonctionnalités offertes par le logiciel représentent les services offerts.

Nous allons illustrer tout ce qui a été dit plus haut sur les services par un exemple. Supposons que vous développez une application logicielle de gestion de stocks et que dans cette application vous avez besoin d'implémenter des fonctions de géolocalisation. Au lieu de développer vous-même les fonctions de géolocalisation dans votre application, vous faites appel à Google et implémentez son service de géolocalisation Google Earth dans votre logiciel via un ensemble d'API offertes par Google. Dans ce cas de figure, votre application est un client de Google, Google Earth est le service offert, et Google est le fournisseur. Votre application ne sait pas comment Google Earth fournit les fonctionnalités du service, elle ne fait que consommer les résultats de ces fonctionnalités à travers les API fournies. Une API (Application Programming Interface, littéralement Interface de Programmation Applicative) est une interface, une sorte de pont de connexion entre deux applications, dans lequel sont exposées un ensemble de méthodes à utiliser pour faire appel aux fonctionnalités offertes par le service. C'est l'ensemble des fonctionnalités offertes par le service qui est qualifié de contrat. L'API est le contrat passé entre le fournisseur de service et le client. Il définit ce que le client peut ou ne peut pas faire. L'API se présente sous forme d'une classe et chaque méthode se présente sous forme d'une fonction qui expose une fonctionnalité précise du service. Un fournisseur peut décider d'exposer une ou plusieurs méthodes de son service, par exemple un service peut avoir dix méthodes dans son ensemble, mais le fournisseur décide d'exposer ou d'en rendre public (dans le jargon technique) que trois. Le client n'utilise le service que par appel des méthodes exposées dans l'API. C'est pourquoi on dit dans la littérature informatique qu'une API est un contrat, le contrat d'utilisation du service. L'avantage de cette approche architecturale est qu'elle vous évite d'avoir à développer vous-même et maintenir des fonctionnalités qui ne sont pas au cœur du besoin métier que votre application implémente. Avec ElasticSearch et beaucoup d'autres applications de l'écosystème Hadoop, c'est le cas : vous développez une application qui exploite des fonctionnalités exposées, ce qui vous évite d'avoir à gérer vous-même dans l'application la complexité de l'exécution distribuée. Ainsi, la démarche orientée services (SOA) est une démarche très efficace pour répondre aux besoins d'interopérabilité et de réutilisabilité de différentes applications. La figure suivante illustre l'architecture de fonctionnement d'un logiciel développé selon une approche orientée services.

Attention tout de même à ne pas confondre une API avec un protocole. Un protocole est une spécification, un langage qui permet à deux ou plusieurs ordinateurs ou applications de communiquer, tandis que l'API expose les méthodes qui leur permettent de communiquer. Dans la démarche orientée services, l'application cliente et le fournisseur sont capables de communiquer uniquement si le client est compatible avec le protocole du fournisseur du service. Prenons l'exemple d'un protocole classique : l'ODBC (Open Data Base Connectivity). Ce protocole est le standard utilisé pour connecter un serveur de base de données et un client. Supposons que vous développez une application en Visual BASIC et vous utilisez l'API ADO (ActiveX Data Objects) qui expose certaines fonctionnalités d'une base de données Oracle. Si la base Oracle n'est pas compatible avec le protocole ODBC, alors même si l'API ADO que vous utilisez expose les fonctionnalités de la base Oracle, votre application Visual Basic ne pourra pas se connecter avec la base de données Oracle. Pour que deux applications puissent se connecter, il faut obligatoirement qu'elles soient compatibles avec le même protocole de communication. En fait, c'est le protocole qui permet de définir les deux types de services qui existent actuellement : les services que nous allons qualifier d'« applicatifs », qui s'appuient sur des protocoles applicatifs comme le JDBC, l'ODBC, ou encore l'OLE DB ; et les services web, qui s'appuient sur les protocoles Web tels que le HTTP et qui permettent d'appeler des services depuis Internet. La différence avec les services applicatifs est que la compatibilité de protocole entre les clients et les fournisseurs de service n'est plus nécessaire puisque le fournisseur du service est distant, accessible par un protocole web ; dans ce cas de figure, l'API offerte par le service continue d'être le contrat, mais n'est plus le canal par lequel le client envoie ses requêtes et reçoit les réponses, plutôt il utilise un format d'échange de fichier, le XML (de plus en plus utilisé), ou le JSON pour décrire ses requêtes et recevoir ses réponses. Voilà ! Ce petit condensé sur les services va vous permettre de mieux comprendre le REST, l'utilisation d'ElasticSearch et l'impact de la démarche orientée services sur les applications distribuées.

À ce stade, tous les éléments sont réunis pour que vous ayez la maîtrise du REST. Dans ce point, nous n'allons pas entrer dans les spécificités du REST, nous allons juste expliquer les principes fondamentaux nécessaires pour utiliser une API REST. Comme nous l'avons dit à l'introduction de cette partie, REST est un modèle d'architecture d'applications orientées services devant fonctionner dans un environnement distribué de type client-serveur. Pour faire simple, REST est un ensemble de bonnes pratiques à respecter pour développer des services. Il a été mis au point au départ pour le développement des services Web (Roy Fielding, l'auteur du REST, est un des principaux créateurs du HTTP), mais après avoir lu ce que nous avons exposé précédemment, vous comprenez que le REST peut s'utiliser aussi bien pour les services Web que pour les services applicatifs. Les services qui sont basés sur l'architecture REST sont appelés les services RESTful. Ainsi, lorsque vous entendrez RESTful, sachez qu'il s'agit d'un service qui respecte les principes de l'architecture REST.

Dans l'architecture REST, le modèle de communication reste le modèle client-serveur : des clients REST font la demande d'une ressource à un serveur REST qui leur en fournit l'accès. Les ressources sont identifiées de façon unique par leur URI (Uniform Ressource Identifier) et s'accèdent à l'aide des méthodes du protocole HTTP. Tout comme dans le Web le format d'échange utilisé pour transmettre les réponses aux requêtes HTTP est le HTML, dans le REST, le format d'échange utilisé pour transférer les ressources est le JSON (le XML est aussi souvent utilisé). Ainsi, l'API d'un service RESTful expose les fonctionnalités d'une application sous forme de ressources accessibles à l'aide de simples méthodes GET, PUT, POST, DELETE ou PATCH. La force du REST vient du fait qu'il s'appuie sur le protocole HTTP pour la communication entre le client REST et le serveur REST, ce qui fait de lui une alternative efficace aux autres protocoles de communication à distance tels que le RPC (Remote Procedure Call) utilisé en MapReduce pour le transfert des données des nœuds Map pour les nœuds Reduce.

REST considère chaque objet exposé comme une ressource. Le terme « ressource » dans le REST est un concept similaire à un objet en programmation orientée objet ou à une entité dans le MCD d'une base de données. Il représente tout élément qui peut être nommé et référencé par un lien hypertexte, tel qu'un fichier, une page HTML, une image, une vidéo, etc. Il est donc important de garder à l'esprit que la réponse renvoyée par le serveur REST n'est pas la ressource elle-même, mais sa représentation. Cette représentation s'appuie sur un format de fichier tel que le JSON. Ainsi, lorsque vous faites la requête d'une ressource, vous obtenez un fichier JSON décrivant cette ressource. Par contre, l'API RESTful par laquelle vous accédez à la ressource la manipule réellement. La ressource est identifiée de façon unique à l'aide d'une URI qui s'écrit selon la syntaxe suivante : protocole://host:port/Ressources/RessourceID ou simplement protocole://host/Ressources/RessourceID. Aussi, il n'est pas rare de voir des architectures REST présentant les URI selon cette syntaxe :

protocole://host/Ressources?method=nom_de_methode&param=parametre_de_methode

La ressource s'accède à l'aide de son URL via un verbe du protocole HTTP. La figure suivante illustre tout ce que nous venons de dire sur le REST en relation avec les services.

Illustrons tout ce que nous avons dit sur les services RESTful par un exemple afin que ce soit plus concret pour vous. Supposons que nous souhaitons réaliser un service REST pour gérer les livres d'une bibliothèque. Le service doit nous permettre de pouvoir ajouter, modifier, lire et supprimer ces livres. Les livres constituent la ressource à manipuler. Supposons que le serveur a pour adresse

http://bibliotheque/. Les livres auront pour URI : http://bibliotheque/livres/livre_id. À l'aide d'un outil comme postman, on pourrait adresser les requêtes suivantes :

• lire le livre 4 : « GET http://bibliotheque/livres/4 » ;
• modifier le livre 10 : « POST http://bibliotheque/livres/10 » ;
• supprimer le livre 5 : « DELETE http://bibliotheque/livres/5 ».

Vous avez maintenant toutes les armes en main pour comprendre comment exploiter ElasticSearch. N'hésitez pas à relire ces points, car la maîtrise des principes qui y sont exposés vous servira pour aborder aisément les prochains points du tutoriel.