REST … zen

Nous avons vu précedemment ce qu’est « NoSQL ». Avant de donner un exemple de base de données (couchDB) que j’aborderai prochainement, parlons d’abord de REST sur lequel l’architecture des bases de données NoSQL se reposent généralement.

Alors qu’est ce que REST ?

REST (Representational State Transfer) est une manière de construire une application pour les systèmes distribués comme le World Wide Web. Le terme a été inventé par Roy Fielding en 2000 dans sa thèse de Ph.D.

REST est un style d’architecture web axé sur l’exploration via des liens en exploitant pleinement les capacités du protocole HTTP. Les services web ou bases de données suivant ce concept possèdent une architecture où le serveur n’a pas à connaître le client spécifique auquel il s’adresse. Comme le client ne fait que suivre des liens, l’un après l’autre, la notion « d’état » du client n’a même pas à être connue par le serveur : c’est le client qui sait où il est, et où il va aller à l’étape suivante. REST repose sur les standards qui fondent l’infrastructure du Web et c’est là son paradoxe : on ne peut pas pour autant en écrire de spécification précise. REST est un style d’architecture, pas une architecture concrète qui sert de standard : il n’existe pas de spécification du W3C pour la décrire. Il s’agit plutôt d’un « mode de compréhension du Web » sur lequel le développeur construit ses services.

L’information de base, dans une architecture REST, est appelée ressource. Toute information qui peut être nommée est une ressource : un article d’un journal, une photo, un service
ou n’importe quel concept. Une ressource est identifiée par un identificateur de ressource. Il permet aux composants de l’architecture d’identifier les ressources qu’ils manipulent. Sur le web ces identificateurs sont les URI (Uniform Resource Identifier). Les composants de l’architecture manipulent ces ressources en transférant des représentations de ces ressources. Sur le web, on trouve aujourd’hui le plus souvent des représentations au format HTML ou XML. Il est important de préciser que l’identificateur d’une ressource doit être une URI unique et non une URL. URL(Uniform Resource Locator) est un chemin d’accès et non un identifiant. Par exemple, http://www.twitter.com est un chemin d’accès à des flux d’information et non une identification d’un flux précis.

REST est une architecture partant du principe selon lequel Internet est composé de ressources accessibles à partir d’une URL. Par exemple, pour avoir le temps à Paris, un utilisateur
pourrait utiliser une adresse de la forme http://www.meteo.fr/paris/. « Paris » serait alors une ressource. REST est également un type d’architecture pour les systèmes distribués qui propose
de représenter un modèle de données et des services sous la forme de ressources. L’idée est de se reposer sur des méthodes standards du protocole HTTP pour manipuler une ressource. Simplement, REST part du principe selon lequel HTTP suffit largement à l’ensemble des besoins d’un service ou d’une application Web, pour peu qu’on utilise l’ensemble des méthodes de ce protocole. L’accès à une ressource par un composant se fait par appel à cette ressource grâce à son URI en utilisant le protocole HTTP. HTTP implémente les verbes GET, HEAD, PUT, POST, DELETE, etc. (ah bon? il y a d’autres verbes HTTP que GET et POST? … :p) qui permettent aux composants de manipuler les ressources de manière simple et « intuitive ». Lorsqu’un client web récupère un URI, il sait qu’il peut récupérer une représentation de cette ressource en déréférençant l’URI avec la méthode GET.

Alors, selon l’école, il peut y avoir des interprétations légèrement différentes des verbes (appelées aussi méthodes)  POST et PUT . Je vais donc vous donner ma version (bien évidemment celle qui me semble la plus appropriée)

POST : Modification ou ajout d’une nouvelle ressource

PUT : Modification ou ajout d’une nouvelle ressource

Mais si PUT et POST permettent d’ajouter/modifier une ressource, laquelle est la plus adéquate?

J’utilise PUT  pour ajouter une nouvelle ressource lorsque l’emplacement de la nouvelle ressource est déjà défini dans l’URI, sinon j’utilise POST.

J’utilise PUT lorsque je renseigne toutes les informations nécessaires à la création/modification de la ressource. Sinon j’utilise POST.

Ce dilemme d’utiliser POST ou PUT est un vrai casse tête pour les « débutants » (ceux qui n’ont pas l’habitude d’utiliser les méthodes HTTP). L’article de John Calcote (très explicite) sur ce sujet m’a bien éclairé sur leur différence donc je vous laisse le lire pour plus amples informations.

J’espère avoir pu vous expliquer ce qu’est REST … à bientôt pour couchDB ^^

Publicités
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :