Pour enlever toute ambiguïté, REST (Representational State Transfert) est un style d’architecture, ce n’est pas un protocole! Ce style a été initié en 2000 par Roy Fielding dans sa thèse de doctorat. Pour comprendre ce concept, je vous invite à regarder la vidéo ci-dessous.

Les principes de REST

• Client-serveur: le client et le serveur sont indépendants, aucune contraintes ne doit les liés
• Stateless: chaque requête doit contenir toutes les informations nécessaires pour être interprété. Le serveur ne contient pas de contexte du client!
• Cache: les réponses du serveur contiennent une information sur la possibilité de cache du contenu (durée de validité)
• Interface uniforme: il convient d’utiliser des interfaces simples, on utilise GET, PUT, DELETE, POST pour agir sur des ressources identifiés
• Un système hiérarchisé: principes qui permet de monter en charge son système simplement (scalability). Le client n’est pas directement connecté au serveur final. Les systèmes intermédiaires, le client et le serveur sont distincts (couches séparées), afin que chaque couche puissent être améliorée sans contraintes.
• Code On Demand: le client dispose de code source qu’il peut exécuter (au lieu de s’exécuter sur le serveur). Cela peut correspondre à des scripts (Javascripts).

Les ressources

En REST on accède à des collections de ressources (ou une ressource en particulier). Ces ressources sont référencées par un identifiant unique. On utilise les standards HTPP pour interagir (Create Read Update Delete) avec ces ressources (GET, PUT, DELETE, POST).

Exemple:

• GET /livre/13    –> retourne le livre identifié par 13
• GET /clients      –> retourne une collection de clients
• DELETE /commentaire/3 –> supprime le commentaire 3

Les méthodes

Un peu de vocabulaire:

• idempotent: PUT et DELET sont « idempotent », ce qui signifie que plusieurs demandes identiques devraient avoir le même effet qu’une seule demande
• safe: GET est une méthode sûre. Cette méthode ne change pas l’état du serveur.

En pratique

Le style d’architecture REST commence à se développer: webservices, sites web. A mon sens ce style d’architecture est une bonne pratique d’urbanisation.

Cependant quelques principes sont encore difficiles à concevoir dans notre mode de fonctionnement habituel: stateless, interface uniforme.

• Stateless: la gestion des contextes et sessions utilisateur est une contrainte
• Interface uniforme: les standards HTTP proposent PUT et DELETE, mais ces méthodes sont méconnues

Les frameworks s’orientent de plus en plus vers ce type d’architecture, mais le changement est lent. Les systèmes REST en productions sont encore trop rares.

Sources: http://fr.wikipedia.org/wiki/Representational_State_Transfer, http://en.wikipedia.org/wiki/Representational_State_Transfer