L’architecture REST orientée ressources

Le World Wide Web se base sur une multitude de composants, bien plus que les utilisateurs ne peuvent l’imaginer. Il n’y a pas que des internautes qui ont recours aux ressources, données et contenus présents grâce à différents projets Web, mais également des machines. Le principe est le suivant : lorsqu’un administrateur de site met son projet en ligne, il convient également de la mettre à disposition d’autres applications et services Web. Le réseau social Twitter est un bon exemple pour illustrer cela. Grâce à un service Web adapté, toutes les applications au choix peuvent lire ou retransmettre des tweets au nom d’un utilisateur de la plateforme de microblogging.

Pour mettre en place un service Web REST, il existe différentes techniques, comme le protocole d’interrogation Remote Procedure Call (RPC), le protocole réseau SOAP, ou encore le paradigme de programmation Representational State Transfer (REST), dont nous allons approfondir le fonctionnement au cours de l’article.

Le concept du Representational State Transfer  nous vient de Roy Fielding en 2000. C’est un des principaux développeurs de standards Web accessibles. Fiedling y décrit de manière abstraite cette architecture populaire du World Wide Web (protocole HTTP, HTML et analyseur XML, applications Web/serveur etc.). En principe, l’architecture REST ne dépend pas d’un protocole en particulier. Le concept central repose obligatoirement sur les ressources suivantes selon Fielding :

• Adressabilité : chaque ressource, par exemple, une commande, un produit ou un article doit pourvoir être identifié par un Unique Resource Identifier (URI).

• Interface homogène : chaque ressource doit pouvoir être facilement 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éralement, le principe de la structure client-serveur est appliqué lorsque le serveur met un service à disposition qui peut être demandée par un client.

• Serveur sans état : la communication entre le serveur et le client doit être sans état, car chaque requête du client vers le serveur doit contenir les informations requises afin de permettre au serveur de traiter la requête, sans qu’il n’y ait de dépendance d'un contexte conservé sur le serveur.

• Différentes représentations des ressources : chaque ressource peut afficher différentes représentations. En fonction des exigences du client, différents langages ou formats comme HTML, JSON ou XML devront être utilisés par exemple.

• Hypermédia : la mise à disposition des ressources a lieu via Hypermedia, 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 uniquement avec des URLs mises à disposition par le serveur, « en fonction du principe Hypermedia as the Engine of Application State » (HATEOAS).

Le style architectural de l’application REST permet le développement de services structurés, qui sont faciles à intégrer et qui communiquent via un protocole harmonisé (HTTP). Grâce à la structure orientée ressources, il est possible de renoncer à la recherche de protocoles d’applications lors de la conception d’un service Web REST, tandis que cette étape est nécessaire avec les alternatives comparables (telles que SOAP).

Afin de mettre en place un service Web REST, HTTP et sa version cryptée HTTPS, seront nécessaires. 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 relativement simple, sans avoir recours à des implémentations en particulier. De plus, le standard HTTP définit de nombreuses commandes, avec lesquelles il est possible d’avoir recours aux ressources suivantes :

La palette de commandes nécessaires peut être élargie à l’aide de l’implémentation d’autres protocoles. Généralement, le protocole WebDAV est implémenté, et comprend les méthodes suivantes :

• COPY (copie des ressources)

• MOVE (déplacement des ressources)

• LOCK (verrouiller les ressources)

• UNLOCK (déverouiller les ressources)

• MKCOL (créér un répertoire)

Bien souvent, ce sont les méthodes standard GET, POST, PUT/PATCH et DELETE via HTTP qui sont mises en œuvre pour le développement d’un service Web REST. Cette architecture est avant tout adaptée à la gestion de données simples. Le principe du sans-état des ressources REST semble diminuer les possibilités de l’architecture. Avec un traitement adéquat des ressources, l’interface REST offre de nombreuses possibilités en dehors du simple ajout d’ensemble de données, comme par exemple :

• Services Web avec traitement des transactions : pour mettre sur place un projet de service Web avec traitement des transactions, un gestionnaire est indispensable. Sachant que toutes les ressources sont sauvegardées entre deux requêtes de par leur nature sans-état, l’utilisation de REST offre deux possibilités :

1. Les ressources sont créées de manière à ce que les transactions puissent être travaillé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 transactions. Chaque requête créée automatiquement une autre ressource qui sera identifiée par un URI et représente une transaction qui va de pair. Les modifications peuvent par la suite être stockées sur le serveur.

• Services Web asynchrones : il est souhaitable pour certains services Web que la requête et la réponse soient couplées. Comme HTTP ne propose pas de mécanismes pour cela, la seule option qui persiste consiste à gérer soi-même les requêtes en tant que prestataire de services et de transmettre les requêtes précises des utilisateurs.

• Services Web avec interopérabilité : les services REST se démarquent par leur grande flexibilité. Les clients mobiles bénéficient également de la souplesse de l’architecture REST et les ressources sont trouvées facilement par les moteurs de recherche.

L’architecture REST livre d’excellents moyens pour constituer et mettre en place des services Web de toutes sortes. Comme la quasi-totalité des appareils est compatible avec Hypertext Transfer Protocol, les clients mobiles et desktop peuvent travailler avec l’interface REST sans encombre et sans applications supplémentaires.

Les services Web se caractérisent grâce à cela par les critères suivants :

• Indépendance vis-à-vis des plateformes,

• Évolutivité,

• Performance,

• Interopérabilité,

• Flexibilité

Leur utilisation requiert néanmoins un minimum de connaissances au préalable, notamment lorsque l’on utilise différentes ressources en parallèle. Pour les habitués des protocoles tels que SOAP, il est plus difficile d’effectuer la transition avec REST, mais cela permet de bénéficier d’un service pratique et utilisable dans différents contextes de travail.