2006/4/14, Ã?ric Daspet [email protected]:
simply_RESTful
http://svn.jamisbuck.org/rails-plugins/simply_restful/
Le plugin a été rapatrié sur le répositoire (*) de Rails ce week-end,
au fait.
Ca c’est excellent, j’avais été obligé de faire un controlleur perso
qui redéfinit des trucs pour implémenter quelque chose d’équivalent.
Faire en sorte que ce soit le framework qui propose une interface
REST est une bonne idée.
Tout récent, un tuto sur REST et Rails, utilisant le plugin
RESTful Rails (http://restful-rails.rubyforge.org/ ) :
http://www.xml.com/pub/a/2006/04/19/rest-on-rails.html?page=1
-- Jean-François.
On 4/21/06, Eric D. [email protected] wrote:
Je suggère fortement le très courant “dépot” pour cet usage. J’ai aussi vu
“entrepot” même si ça me plait un peu moins
Dépôt est le terme le plus souvent utilisé et fort adapté, j’abonde.
Ollivier R. -
2006/4/14, Ã?ric Daspet [email protected]:
simply_RESTful
http://svn.jamisbuck.org/rails-plugins/simply_restful/
Le plugin a été rapatrié sur le répositoire (*) de Rails ce week-end,
au fait.
Merci de l’info
Je suggère fortement le très courant “dépot” pour cet usage. J’ai aussi vu
“entrepot” même si ça me plait un peu moins
–
Eric D.
Salut,
J’ai pas tout compris à REST.
Ca apporte quoi vu que l’on gère déjà dans Rails des routes et des
urls “logiques” et que l’on a des templates rxml.
Ciao’
Tout récent, un tuto sur REST et Rails, utilisant le plugin
RESTful Rails (http://restful-rails.rubyforge.org/ ) :
Putting REST on Rails
Après avoir jeté un oeil : contentez vous du simpleRest dans rails. Ce
plugin là est outrageusement complexe, peu pratique, et en plus risque
d’être tordu à implémenter : la gestion de la ressource et de sa
collection se fait dans le même controleur, ce qui me parait un raccourci
trop important (comment je fais avec le mot clé qui est la collection de
mon article qui est la collection de mom commentaire ?). Dommage parce
qu’en échange il ajoute des choses sympa coté automatisation HTTP.
–
Eric D.
Salut,
J’ai pas tout compris à REST.
Ca apporte quoi vu que l’on gère déjà dans Rails des routes et des
urls “logiques” et que l’on a des templates rxml.
Si tu ne fais que lire des docs à partir d’un navigateur avec des url
“logiques” alors ça n’apporte rien parce que ce que tu fais c’est déjà du
REST.
Maintenant tu ne fais pousses probablement pas la philosophie REST au
bout. Pour effacer un document tu passes certainement par un bouton ou
un
lien. Du coup ton navigateur envoie une requête de type POST (ou un GET)
avec un ordre (effacer) en paramètre. Pour créer un nouveau document tu
passes certainement par un formulaire, ce formulaire s’adresse à une page
“creation_document” en transmettant plein d’infos en paramètres
séparéspour que la page puisse récréer correctement le document sur le serveur.
Le principe derrière REST c’est que le protocole HTTP permet déjà de gérer
des ressources et des ordres : un message HTTP c’est un ordre, des
paramètres, des entêtes, un contenu (la ressource).
Si je veux effacer je m’adresse directement à l’adresse de mon document et
je lui fais une requête “DELETE” au lieu de passer par une page tierce qui
ne représente rien et envoyer un ordre illogique avec “efface” en
paramètre.
Si je veux créer un document je m’adresse à l’url de la collection (celle
qui généralement se termine par un /) et j’envoie mon document directement
(sans le décomposer dans un formulaire, sans le traiter/reformater) avec
un ordre “POST”.
Voir : http://svn.jamisbuck.org/rails-plugins/simply_restful/README
Au niveau rails ça veut dire qu’au lieu de se baser sur des actions et des
groupes d’actions (les controlleurs) qui vont déclencher des affichages,
on va manipuler des ressources sur lesquelles on va pouvoir agir (créer,
supprimer, lire, …). C’est je pense plus naturel et plus proche de la
philosophie objet.
L’avantage de se coller au plus proche de rest c’est que tous les outils
et toutes les fonctionnalités sont déjà
là.- authentification ? déjà présent dans HTTP et géré partout ou presque
- gestion des caches, des timeout, des vérifications de mise à jour ? déjà
dans HTTP et géré correctement par la grande majorité des bibliothèques
HTTP
- gestion de la compression, récupération d’une sous partie d’un document,
découverte automatique des actions qu’on peut faire sur une ressources …
tout ça aussi est dans HTTP et est le plus souvent déjà
implémenté.
On s’oppose ainsi par exemple à la philosophie SOAP qui a recréé tout un
langage en XML pour gérer par dessus HTTP tout ce qui existait déjà. Du
coup en SOAP on utilise un ordre HTTP bidon et on transmet l’ordre réel
dans le XML. Toujours en SOAP au lieu de gérer les erreurs ou de
transmettre la ressource directement dans la réponse, on va les encapsuler
dans des structures XML complexes.
Ce qu’on voit généralement en Web c’est un intermédiaire : des pages
simples qui respectent rails, et des formulaires
d’édition/suppression/création qui réimplémentent tout au dessus de HTTP
au lieu d’utiliser HTTP.
–
Eric D.
Le 21/04/06, Eric D. [email protected] a écrit :
(…)
L’explication d’Eric est exellente, je veux juste ajouter quelque infos.
en fait c’est la method (attribut de formulaire entre autre) qui est
utilisé
pour REST
Get pour faire de la lecture
Post pour de l’insertion
Put pour de la Maj
et Delete pour supprimer.
C’est du WebServices HTTP.
Soap est utile mais souvent mal utilisé. Soap c’est bien pour de la
communication entre application, c’est à dire pas forcement (voir pas du
tout) via HTTP mais d’autres protocole (je sais plus trop mais je crois
que
UDP en est un)
Soap est tres verbeux, Rest permet d’utilisé les entete HTTP pour
définir un
ordre et donc n’envoyer en paramètre que ce qui est necessaire:
Pour un Get: aucun paramètre, tout est dans l’URL (
http://monsite/monservice/monobjet/monsousobjet1/monsousobjet2/monattributpar
exemple)
pour un Post: les paramètre de l’objet à inserer
pour un Put: " "
et pour un Delete: normalement aucun paramètre, c’est comme un Get mais
pour
de la suppression
Ce qui permet de réduire considérablement la quantité d’information
transitant sur le réseau et donc d’amélioré sensiblement les
performances.
Mais surtout ça permet d’être plus clair et de ne pas re-inventer la
roue.
Personnelement, je n’ai pas encore beaucoup travailler avec Rails, mais
je
regrette de voir si peut d’application web se baser sur ce principe
tellement élémentaire … (point de vue perso inside :-p )
Voilou.
A bientot.
Salut Mathieu,
J’ai pas tout compris à REST.
Ca apporte quoi vu que l’on gère déjà dans Rails des routes et des
urls “logiques” et que l’on a des templates rxml.
une réponse en coup de vent,
on a des “smart url” en Rails, mais on s’en sert pour naviguer
pour que les urls soient plus simples à bookmarquer, à taper
à la main ou juste par souci de clarté.
REST c’est différent, c’est pour faire du RPC en quelque sorte,
c’est plus un concurrent de XML-RPC ou de SOAP…
(d’ailleurs j’étais en train de me dire que Google a une API SOAP
mais pas REST ??)
C’est plus simple et moins “over-bloated”. C’est peut-etre
d’ailleurs pour ça que DHH souhaite enlever AWS de RoR et
pousser plus en faveur de REST. C’est plus “Keep it simple
stupid”.
Bon, je laisse les autres compléter.
-- Jean-François.
2006/4/21, Mathieu C. [email protected]:
Mais juste une autre question, à quoi ça ressemble les dans le
cas d’un ajout ou modif ? C’est précisé dans le protocole, c’est normé
?
Et bien c’est comme tout paramètre passé en post dans une requete http:
== entete HTTP ==
xxxxxxxxxx
== /entete http ===
nomduparametre=valeur
nomduparametre2=valeur2
Merci pour ton post Eric, effectivement c’est limpide.
Voir la note de bas de page de Dave T. dans le PickAxe à propos de
SOAP qui dit que le S (pour Simple) a disparu depuis longtemps.
J’imagine enfin un client SAP bash à coups de netcat 
update an existing message
response = http.put("/message/1", “……”)
Mais juste une autre question, à quoi ça ressemble les dans le
cas d’un ajout ou modif ? C’est précisé dans le protocole, c’est normé
?
Ciao’
Mathieu