L’ar­chi­tec­ture REST orientée res­sources

Le World Wide Web se base sur une multitude de com­po­sants, bien plus que les uti­li­sa­teurs ne peuvent l’imaginer. Il n’y a pas que des in­ter­nautes qui ont recours aux res­sources, données et contenus présents grâce à dif­fé­rents projets Web, mais également des machines. Le principe est le suivant : lorsqu’un ad­mi­nis­tra­teur de site met son projet en ligne, il convient également de la mettre à dis­po­si­tion d’autres ap­pli­ca­tions et services Web. Le réseau social Twitter est un bon exemple pour illustrer cela. Grâce à un service Web adapté, toutes les ap­pli­ca­tions au choix peuvent lire ou re­trans­mettre des tweets au nom d’un uti­li­sa­teur de la pla­te­forme de mi­cro­blog­ging.

Pour mettre en place un service Web REST, il existe dif­fé­rentes tech­niques, comme le protocole d’in­ter­ro­ga­tion Remote Procedure Call (RPC), le protocole réseau SOAP, ou encore le paradigme de pro­gram­ma­tion Re­pre­sen­ta­tio­nal State Transfer (REST), dont nous allons ap­pro­fon­dir le fonc­tion­ne­ment au cours de l’article.

Le concept du Re­pre­sen­ta­tio­nal State Transfer  nous vient de Roy Fielding en 2000. C’est un des prin­ci­paux dé­ve­lop­peurs de standards Web ac­ces­sibles. Fiedling y décrit de manière abstraite cette ar­chi­tec­ture populaire du World Wide Web (protocole HTTP, HTML et analyseur XML, ap­pli­ca­tions Web/serveur etc.). En principe, l’ar­chi­tec­ture REST ne dépend pas d’un protocole en par­ti­cu­lier. Le concept central repose obli­ga­toi­re­ment sur les res­sources suivantes selon Fielding :

• Adres­sa­bi­lité : chaque ressource, par exemple, une commande, un produit ou un article doit pourvoir être identifié par un Unique Resource Iden­ti­fier (URI).

• Interface homogène : chaque ressource doit pouvoir être fa­ci­le­ment utilisée et de manière homogène, grâce à des méthodes standard. Par exemple avec les méthodes « GET », « POST » ou « PUT » en HTTP.

• Structure client-serveur : gé­né­ra­le­ment, le principe de la structure client-serveur est appliqué lorsque le serveur met un service à dis­po­si­tion qui peut être demandée par un client.

• Serveur sans état : la com­mu­ni­ca­tion entre le serveur et le client doit être sans état, car chaque requête du client vers le serveur doit contenir les in­for­ma­tions requises afin de permettre au serveur de traiter la requête, sans qu’il n’y ait de dé­pen­dance d'un contexte conservé sur le serveur.

• Dif­fé­rentes re­pré­sen­ta­tions des res­sources : chaque ressource peut afficher dif­fé­rentes re­pré­sen­ta­tions. En fonction des exigences du client, dif­fé­rents langages ou formats comme HTML, JSON ou XML devront être utilisés par exemple.

• Hy­per­mé­dia : la mise à dis­po­si­tion des res­sources a lieu via Hy­per­me­dia, par exemple sous forme d’attributs « href » et « src » dans des documents HTML ou pour l’interface définie des éléments JSON et XML. Ainsi, le client d’une API REST navigue uni­que­ment avec des URLs mises à dis­po­si­tion par le serveur, « en fonction du principe Hy­per­me­dia as the Engine of Ap­pli­ca­tion State » (HATEOAS).

Le style ar­chi­tec­tu­ral de l’ap­pli­ca­tion REST permet le dé­ve­lop­pe­ment de services struc­tu­rés, qui sont faciles à intégrer et qui com­mu­ni­quent via un protocole harmonisé (HTTP). Grâce à la structure orientée res­sources, il est possible de renoncer à la recherche de pro­to­coles d’ap­pli­ca­tions lors de la con­cep­tion d’un service Web REST, tandis que cette étape est né­ces­saire avec les al­ter­na­tives com­pa­rables (telles que SOAP).

Afin de mettre en place un service Web REST, HTTP et sa version cryptée HTTPS, seront né­ces­saires. HTTPS est très répandu et presque tous les ports requis du pare-feu y sont ouverts. De plus, le protocole sans statut Hypertext Transfer Protocol est construit de manière re­la­ti­ve­ment simple, sans avoir recours à des im­plé­men­ta­tions en par­ti­cu­lier. De plus, le standard HTTP définit de nom­breuses commandes, avec les­quelles il est possible d’avoir recours aux res­sources suivantes :

La palette de commandes né­ces­saires peut être élargie à l’aide de l’im­plé­men­ta­tion d’autres pro­to­coles. Gé­né­ra­le­ment, le protocole WebDAV est im­plé­menté, et comprend les méthodes suivantes :

• COPY (copie des res­sources)

• MOVE (dé­pla­ce­ment des res­sources)

• LOCK (ver­rouil­ler les res­sources)

• UNLOCK (dé­ve­rouil­ler les res­sources)

• MKCOL (créér un ré­per­toire)

Bien souvent, ce sont les méthodes standard GET, POST, PUT/PATCH et DELETE via HTTP qui sont mises en œuvre pour le dé­ve­lop­pe­ment d’un service Web REST. Cette ar­chi­tec­ture est avant tout adaptée à la gestion de données simples. Le principe du sans-état des res­sources REST semble diminuer les pos­si­bi­li­tés de l’ar­chi­tec­ture. Avec un trai­te­ment adéquat des res­sources, l’interface REST offre de nom­breuses pos­si­bi­li­tés en dehors du simple ajout d’ensemble de données, comme par exemple :

• Services Web avec trai­te­ment des tran­sac­tions : pour mettre sur place un projet de service Web avec trai­te­ment des tran­sac­tions, un ges­tion­naire est in­dis­pen­sable. Sachant que toutes les res­sources sont sau­ve­gar­dées entre deux requêtes de par leur nature sans-état, l’uti­li­sa­tion de REST offre deux pos­si­bi­li­tés :

1. Les res­sources sont créées de manière à ce que les tran­sac­tions puissent être tra­vail­lées au cours d’une requête.
2. Une ressource est créée de manière à ce que les requêtes soient gérées par les tran­sac­tions. Chaque requête créée au­to­ma­ti­que­ment une autre ressource qui sera iden­ti­fiée par un URI et re­pré­sente une tran­sac­tion qui va de pair. Les mo­di­fi­ca­tions peuvent par la suite être stockées sur le serveur.

• Services Web asyn­chrones : il est sou­hai­table pour certains services Web que la requête et la réponse soient couplées. Comme HTTP ne propose pas de mé­ca­nismes pour cela, la seule option qui persiste consiste à gérer soi-même les requêtes en tant que pres­ta­taire de services et de trans­mettre les requêtes précises des uti­li­sa­teurs.

• Services Web avec in­te­ro­pé­ra­bi­lité : les services REST se dé­mar­quent par leur grande flexi­bi­lité. Les clients mobiles bé­né­fi­cient également de la souplesse de l’ar­chi­tec­ture REST et les res­sources sont trouvées fa­ci­le­ment par les moteurs de recherche.

L’ar­chi­tec­ture REST livre d’ex­cel­lents moyens pour cons­ti­tuer et mettre en place des services Web de toutes sortes. Comme la quasi-totalité des appareils est com­pa­tible avec Hypertext Transfer Protocol, les clients mobiles et desktop peuvent tra­vail­ler avec l’interface REST sans encombre et sans ap­pli­ca­tions sup­plé­men­taires.

Les services Web se ca­rac­té­ri­sent grâce à cela par les critères suivants :

• In­dé­pen­dance vis-à-vis des pla­te­formes,

• Évo­lu­ti­vité,

• Per­for­mance,

• In­te­ro­pé­ra­bi­lité,

• Flexi­bi­lité

Leur uti­li­sa­tion requiert néanmoins un minimum de con­nais­sances au préalable, notamment lorsque l’on utilise dif­fé­rentes res­sources en parallèle. Pour les habitués des pro­to­coles tels que SOAP, il est plus difficile d’effectuer la tran­si­tion avec REST, mais cela permet de bé­né­fi­cier d’un service pratique et uti­li­sable dans dif­fé­rents contextes de travail.