Gilles le 30/06/2007 :

Alors là, chapeau ! Rien à dire. Excellent article. C'est de l'excellent. Très très intéressant, très très bien décrit. C'est du David quoi :) Vraiment merci et bravo. Bon week-end à toi !

Eric Daspet le 30/06/2007 :

> une URI doit être descriptive
Ca n'est pas une contrainte ou même une recommandation de l'architecture orientée ressource. Du point de vue du navigateur, du serveur, et de la ressource, l'URL est un composant opaque. Cette URL n'est pas "comprise", elle n'a pas à être descriptive.
Si l'URL doit être descriptive, c'est uniquement un effet de bord de son positionnement actuel dans les interfaces des navigateurs. On a mis l'URL comme un composant central, accessible et éditable par l'utilisateur. De fait, du coup, l'URL s'échange sous format texte et mérite à être descriptive.
Dans l'idéal l'humain n'a pas à lire l'URL, il n'a pas à la manipuler. Tout ce qu'il a à faire c'est la stocker (par exemple dans ses favoris), l'échanger et la rappeler. Vu notre monde, le stockage est ou va devenir tout électronique (favoris du navigateur, clé usb, téléphone portable). On devrait pouvoir donc à terme se passer de l'URL descriptive : le dispositif électronique nous présentera le titre de la page, la description texte qu'on y a accolé, le site source ... l'URL n'a plus aucun intérêt du point de vue humain. Même chose pour l'échange. On va y arriver très vite avec les QR Code des téléphones portables.
Bref, l'URL descriptive est encore nécessaire dans nos pays (ça doit être moins vrai là où le QR Code est développé) mais ça n'est pas lié à l'architecture RESTE, à HTTP ou au Web. C'est juste une problématique d'interface utilisateur qui mérite d'évoluer (et qui le fera à moyen terme).

David, biologeek le 30/06/2007 :

@Gilles : Merci ! Bon we à toi aussi :-).
@Eric Daspet : je suis d'accord avec le fait que les URL n'ont pas été faites pour les humains mais force est de constater que c'est rentré dans les mœurs et (presque) tout le monde comprend à peu près ce que ça signifie, principalement grâce au nom donné.
Du coup, je ne pense pas qu'elles disparaissent de si tôt des interfaces utilisateurs car on n'a pas encore trouvé mieux... remarque on pourrait presque faire un parallèle entre la ligne de commande et les adresses web et celles-ci on presque disparues donc je m'avance un peu.
Je pense que l'indexation a pris le dessus sur le stockage. Aujourd'hui pour retrouver un favori je cherche pas souvent dans les centaines que j'ai, je le retrouve avec des mots-clés sur un moteur de recherche. C'est d'ailleurs ce qui donne tant (trop !) de puissance aux moteurs de recherche, ils nous guident un peu là où ils ont envie...

syntax_error le 01/07/2007 :

La description des principes est claire, mais j'avoue que j'ai pas compris à quoi ca correspond concrètement en termes de développement. A part éviter les cookies et les sessions, et avoir des urls claires ca manque d'exemples concrets, de modèles ou de comparaisons.
D'après ce que j'en retire l'idée est que chaque requête doit pouvoir s'exécuter indépendament de tout contexte. Cela semble plus un principe qu'une méthode.

Stéphane Bortzmeyer le 01/07/2007 :

> j'avoue que j'ai pas compris à quoi ca correspond concrètement en
> termes de développement
J'espère que le petit exemple qui est ici :
www.bortzmeyer.org/progra...
aidera. Il est tout petit mais fait partie d'un vrai logiciel de gestion de registre (CODEV-NIC).
> A part éviter les cookies et les sessions, et avoir des urls claires
C'est déjà pas mal si on fait tout ça !

David, biologeek le 01/07/2007 :

@syntax_error : patience les exemples arrivent ;-).
@Stéphane Bortzmeyer : merci pour le lien.

Olivier le 16/07/2007 :

Bonjour
Merci pour cet article qui m'a permis de clarifier certaines choses. Je suis un lecteur assidu de ce blog et cette fois-ci, je me lance à rédiger un commentaire ...
Je suis entièrement convaincu du bien fondé et des avantages de cette architecture, mais n'y-a-t-il pas qq soucis concernant la réalisation concrète de "grosses applications", je pense en particulier aux performances (reconstituer l'état complet d'un gros système à chaque requête) ... ou encore à la longueur des URLS ...
Pour le REST ;-) , je suis convaincu qu'il n'y aura bientôt plus de "grosses applications" mais simplement une miriade de petites discutant entre elles ... mais en attendant ...
Merci pour la mine d'info pertinente qu'est ce blog et vivement cette refonte :-)

David, biologeek le 16/07/2007 :

@Olivier : il ne faut surtout pas être si timide ;-).
> n'y-a-t-il pas qq soucis concernant la réalisation concrète de "grosses applications", je pense en particulier aux performances (reconstituer l'état complet d'un gros système à chaque requête) ...
Au niveau des performances, cela ne change rien si ce n'est qu'une application utilisant cette architecture peut reposer sur le cache HTTP qui a fait ses preuves jusqu'à présent (donc il n'y a pas forcément processing à chaque requête). Il est vrai que les exemples d'applications complexes RESTful sont rares pour l'instant mais mon petit doigt me dit que cela ne va pas durer.
> ou encore à la longueur des URLS ...
Une URL peut être très longue www.boutell.com/newfaq/mi... mais si l'on considère des imbrications de ressources vraiment importantes (mais alors là on en arriverait à une complexité énorme) ça pourrait en effet poser problème. Pour l'instant je suis jamais arrivé à plus de 6 ressources imbriquées et c'était pour des workflows bien complexes.
REST n'est donc pas forcément limité aux petites applications même si tous les exemples restent basiques. C'est juste pour expliquer le principe mais on peut faire des choses beaucoup plus attrayantes avec ;-).

Sebmox le 17/07/2007 :

Pour info, le livre mentionné au début par David sort en septembre en version française...
www.oreilly.fr/catalogue/...
Sinon très très bon article !!

Graffiti le 18/07/2007 :

L'url sert (encore un anagrame de rest) aussi pour le référencement... :) on a tendance à l'oublier

Stéphane Bortzmeyer le 25/07/2007 :

Puisque certains ont été assez indulgents pour apprécier mon premier court article (moins bon que celui de David mais avec plus de code), voici un second :
www.bortzmeyer.org/rest-s...

Nicolas Hoizey le 28/11/2007 :

Excellent article, qui me confirme que nous sommes de plus en plus nombreux à utiliser cette architecture, bravo !!!
Juste une précision, sans doute non nécessaire pour la plupart des lecteurs, mais bon :
Tu dis « il n'est pas possible de changer l'adresse du navigateur en JavaScript, excepté les ancres ».
Il faudrait sans doute modifier ça en « il n'est pas possible de changer l'adresse du navigateur en JavaScript sans provoquer le rechargement de la page, excepté pour les ancres ».

David, biologeek le 28/11/2007 :

@Nicolas Hoizey : En effet, bonne précision mais JavaScript est souvent utilisé pour palier justement au rechargement de la page actuellement.

Nicolas Hoizey le 28/11/2007 :

Je suis d'accord, je soulignais juste une imprécision pouvant conduire un lecteur à croire une erreur... ;-)

étudiant blogueur le 25/11/2008 :

je pense qu'il y a erreur dans ce qui suit :
html ou json par exemple
vous voulez dire peut être :
html ou js (javascript) par exemple

David, biologeek le 25/11/2008 :

Non, je parlais bien du format de représentation de données JSON :
http://fr.wikipedia.org/wiki/JavaScript_Object_Notation

Il est lié à la base à JavaScript mais ce n'est pas une erreur de ma part :-)

étudiant blogueur le 26/11/2008 :

Ok c'est noté cher blogueur. Même si je suis développeur je n'y avais jamais entendu parlé.
PS: wikipedia a déjà accumulé $3 000 000 :-0
Merci :)

nfroidure le 02/10/2010 :

Bonjour,

Petit commentaire en réaction à la partie "Sans état".

Pour un service web qui serait, pour sa majeure partie, accessible de manière privée, les sessions ou cookies me paraissent inévitables.

Il y a peut-être la possibilité de distinguer une ressource privée en signifiant dans l'URI qu'elle est privée. Sur twitter ça donnerai ça :
http://twitter.com/private/nfroidure/settings/account
au lieu de :
http://twitter.com/settings/account

Quelles sont les pratiques en la matière pour gérée les droits d'accès sur une application RESTful ?

Merci