Wahou !
Super article, merci beaucoup pour la traduction !
@Country et Thesa : merci.
@Geoffrey : j'ai malencontreusement effacé ton commentaire en supprimant les spams, je suis vraiment vraiment désolé :/
C'est dommage il était intéressant, de mémoire tu mettais en avant le fait qu'il serait mieux que les navigateurs implémentent ces méthodes pour ne pas avoir à faire des hacks de l'utilisation de POST et je suis bien d'accord avec toi !
Le problème c'est l'inertie des navigateurs, il n'y a qu'à voir l'éternel débat entre xhtml2 et html5... du coup les petites bidouilles prennent parfois le dessus car les développeurs web sont plus réactifs ;-).
si je peux me permettre, dans le paragraphe "quatre méthodes" je crois qu'il y a une inversion dans les descriptions de PUT et de POST.
tools.ietf.org/html/rfc26...
@biou : je ne crois pas (cf. fr.wikipedia.org/wiki/Hyp... )
Super article bravo
Maintenant il ne me reste (sans jeu de mot) plus qu'a reprendre mes programme ROR
cordialement
URIs, Addressability, and the use of HTTP GET and POST
www.w3.org/2001/tag/doc/w...
Notamment la checklist
1.3 Quick Checklist for Choosing HTTP GET or POST
Un autre article tres interessant sur le sujet
bitworking.org/news/125/R...
Bonjour David,
Bravo pour cette traduction.
Je me permet de citer un lien vers un de mes posts il y a 6 mois sur ce sujet avec mon point de vue d'architecte du logiciel concernant la scalabilité / échelonnabilité de ce type d'architecture.
En anglais : www.grodziski.com/blog/jc...
Et en français :-) : www.grodziski.com/blog/jc...
Jérémie.
Merci pour ces liens Jérémie qui complètent parfaitement ce billet.
super Ti Geek, marrant de retomber sur ton site en faisant de la veille sur REST...tenté par une virée en Inde pour implementer du REST on Rails?
Mmmh pas encore prêt à faire le grand saut mais qui sait, peut-être plus tard ? :-)
Tu peux peut-être rajouter ma courte présentation vidéo chamia.info/bader/archive...
ainsi que le PDF qui va avec :
journees.afpy.org/present...
Très bonne approche pour comprendre REST. C'est très clair. Merci.
Bonjour
J'ai traduit le chapitre 5 de la thèse de Roy. Fielding. Cela peut compléter la liste des ressources.
opikanoba.org/tr/fielding...
Fred
Oh merci Fred ! J'ai ajouté le lien en ressource.
Excellent article, autant dans la forme que le fond.
Merci :-)
Article très clair et intéressant.
Merci pour ta traduction
Nicolas
Merci beaucoup pour ce billet,
Cela m'a permit de mieux apercevoir Rest, même si c'est encore un peu flou dans ma tête.
Je vais tenter de travailler un peu plus dessus, pour m'éclaircir les neurones.
Merci encore et bon courage pour la suite avec Django.
Azema.
Je vais commencer à écrire une API REST en java, cet article m'a beaucoup aidé pour comprendre comment structurer mon projet.
J'ai une question "pratique", comment faire côté serveur pour avoir autant d'URL?
Je pensais utiliser des servlets mais comment faire avec une URL du type /XXX/<user_id>/getYYY ?
Il faut analyser l'URL?
Merci pour vos réponses.
@bea : oui c'est exactement ça, en fonction des arguments dans l'url, il faut servir une réponse appropriée. Pour java, je sais qu'il existe pas mal de solutions qu'il serait intéressant d'analyser avant de se lancer dans l'écriture d'une nouvelle solution à mon avis. Bon courage :-)
Tu parles d'arguments dans l'url.
Je voudrais savoir pourquoi avoir des URLs du type /XXX/<user_id>/getYYY plutôt que d'avoir une URL et un paramètre user_id.
C'est plus simple de récuépérer les paramètres envoyés en get ou post plutôt que d'analyser l'URL.
J'ai lu que c'était mieux de ne pas passer par des paramètres, pourquoi??
merci
J'en ai pas mal parlé là : www.biologeek.com/journal...
Le but c'est d'avoir une URL unique pour la ressource : /foo/id/. Normalement ton backend doit pouvoir traiter une url et en extraire les arguments (en tout cas les bons frameworks le font).
Je n'avais pas vu le getYYY ton exemple, tu comptes mettre quoi dans YYY ? Normalement tu ne dois pas mettre de verbes dans tes urls, les actions doivent être dictées par les verbes HTTP (GET, POST, PUT et DELETE).
Pour les paramètres, ils ont été déconseillés à la base car ils posaient problème dans le cas du référencement (tout ce qui est après le ? n'était pas considéré par Google). Aujourd'hui, ils restent utile dans le cas de filtres mais ils sont moins employés. Il faut considérer les urls comme les ids de la gigantesque base de données qu'est le web.
Bonjour,
Pour avoir mis en place une architecture REST au sein d'une grande banque, voici quelques inconvénients et difficultés rencontrés :
- Proxy http : les proxys applicatifs sont souvent limitatifs quant aux verbes http autorisés. DELETE et PUT notamment sont souvent bloqués et il faut passer outre en sacrifiant l'esprit REST (ie utiliser POST et GET de façon détournés)
- Librairies clientes : autant les outils du coté serveur sont matures et nombreux (en java : Restlet, Jersey et la JSR 311) autant les librairies du côté client (web notamment) ne sont pas toujours compatibles (exemple client flex : www.fngtps.com/2007/06/fl...)
- Difficultés de mapper des services avec des ressources : l'architecture REST est parfaite pour une serveur de ressources (ie. getUser, postUser etc.) mais pour modéliser une application rendant des services métiers complexes (calculs, règle de gestion etc.) cela devient un vrai casse tête pour créer et mapper les ressources de façon intelligente sans sacrifier la modélisation applicative "standard" du côté serveur
Alex.
Merci pour ce retour très intéressant Alex !
Pour répondre à la problématique de mapping des ressources, je suis aussi confronté à ce problème et c'est pas toujours évident...
Je trouve l'article de Joe Gregorio très intéressant à ce sujet :
bitworking.org/news/201/R...
Ça nécessite une certaine gymnastique du cerveau au début mais qui peut s'avérer utile, à force de retourner un peu l'application dans tous les sens pour identifier les ressources, ça ouvre parfois de nouvelles perspectives intéressantes.
le genre d'article a lire un soir ou la copine n'est pas dans le coin (pour éviter les conversation ressemblant à des monologue "Hey j'ai encore lu un truc trop bien...tu m'écoute?" mais plutot se dire intérieurement avec une certaine satisfaction "Woa c trop cool encore un article qui vas m'en apprendre plus qu'a l'ecole")
bref. nouveaux sur django, je m'en vais direct avaler l'article sur django/REST.
Encore un petit mot pour dire merci sur la qualité de ce blog et sa volonté didactique éfficace (premier commentaire oblige ;) )
Merci, Super article sympa sur REST...
Bonsoir,
L'article est très bien fait, mais je me sent un peu obligé de réagir sur un point. A propos de POST et PUT, si l'on en croit ce document http://tools.ietf.org/html/rfc2616#page-54 , ce serai plutot:
PUT: créer ou modifier la ressource a tel uri, par exemple:
PUT /user/mathieu
avec dans le body:
<user>
<prenom>mathieu</prenom>
<nom>.....</nom>
....
</user>
alors que POST ne signifie pas nécéssairement qu'une ressource sera créer. dans l'application sur laquelle je travaille, on essai d'utiliser POST, seulement quand on ne peux pas utiliser PUT, en général, lorsque l'on ne connais pas à l'avance l'uri qui permettra d'identifier la ressource (par exemple si l'identifiant est un id auto incrémenté de base de donnée)
Cordialement, Mathieu.
@Mathieu : je suis tout à fait d'accord, et c'est ce que je précise dans un billet suivant (qui lui n'est pas une traduction) :
https://larlet.fr/david/biologeek/archives/20070629-architecture-orientee-ressource-pour-faire-des-services-web-restful/
Cela dit, il est assez rare de connaître à partir du client les contraintes appliquées sur le serveur, comme tu le précises.
Bonjour,
Merci pour cette explication claire.
Je suis également dans une situation "J'apprends Ruby + RoR + Le Web dévelopmment+ Ajax + ..."
Donc beaucoup de questions se posent à moi.
Notamment par rapport aux listes de ressources comme dans l'exemple
/aeroports pour la liste des aéroports
/aeroports/orly pour orly
Comment implémente-t-on la notion de filtre ?
Imaginons que je souhaite une liste des aéroports de France. Mon Url serait
/aeroports/france
Comment mon code va-t-il pouvoir identifier que france est une (sous)liste alors que orly est une resource ?
( Je voudrais évidement éviter de devoir demander
/aeroports/france/orly )
Désolé si la question peut paraitre triviale à certains ;-)
Michel
Salut Michel,
Je dirais que tout dépend si le filtre est assimilable à une collection lui-même.
Par exemple, si on veut juste pouvoir filtrer les aéroports en France, on peut passer les arguments en GET :
/aeroports/?country=France
Cette page listera les ressources (dont un lien vers Orly) qui correspondent à des aéroports filtrés pour le pays France.
Maintenant c'est souvent au cas par cas, selon l'importance de la sous-collection en général. Par exemple ici on pourrait avoir /aeroports/france/orly ou /aeroports/orly Quelle URL fait le plus de sens pour cette ressource ? Je serais tenté de dire /aeroports/orly car on a bien collection/ressource mais ça dépend vraiment du projet, parfois il est plus intéressant d'avoir la notion de filtrage par lieu directement dans l'URL. Il n'y a pas de réponse dans l'absolu :-)
Salut Michel,
J'utilise le framework konstrukt en PHP pour créer mon architecture REST. Leur approche est intéressante car ils utilisent la notion de controller. Je te laisse regarder la définition du pattern MVC.
Le principe est le suivant :
1. Chaque URI possède son controller.
Lorsque tu tapes www.monsite.com/aeroports un controller nommé "aeroport_list_controller" va s'occuper de ta requête : par exemple afficher la liste des aéroports. De même si tapes www.monsite.com/aeroports/orly un controller que l'on va appelé "aeroport_show_controller" s'occupera de ta requête, et affichera la liste des avions à orly.
(Suite)
2.Chaque controller possède deux comportement.
Le premier est décrit en 1., le second est de rediriger vers le controller correspondant à ta requête.
Un exemple : je saisie l'url www.monsite.com/aeroports/orly/vols/451. Le premier controller en jeu est "aeroport_list_controller", qui me redirige vers "aeroport_show_controller". "aeroport_show_controller" me redirige vers "vols_list_controller".
"vols_list_controller" me redirige ensuite vers "vols_show_controller" qui affichera le vol 451 au départ d'orly !
3.Chaque controller connait le contexte dans lequel il est appelé, par imbriquation. Ainsi lorsque je saisis aeroports/orly/vols/451, "vols_show_controller" sait que je souhaite afficher le vol 451 au départ d'orly.
Enfin c'est à toi d'implémenter les méthodes GET, POST, PUT et DELETE dans chaque controller.
Bonjour,
cet article est très intéressant, il m'a permis de mieux comprendre REST.
Pour un TP j'ai pu le mettre pratique avec SYMFONY. Cependant, existe-t-il un moyen de tester, en envoyant des headers HTTP avec les différentes commandes (GET, POST, DELETE, ...) ?
Merci pour l'article... Je dois développer sous une architecture REST et ça me semble moins flou.
Et maintenant comment faire avec xmpp ? Il n'y a pas les méthodes de http ? C'est pas grave, parce que peut importe la manière de désigner, ce qui compte c'est la ressource et ce qu'on peut faire avec ! faire(ressource) ~ f(x) on prend x et on cherche les f qui vont avec, et voilà. Le Web est mort, vive Jabber
Superbe article au total, Merci
Merci pour cette introduction pratique à REST
C'est sympa l'approche pour la compréhension de post et de rest.
Comme quoi on peu apprendre en s'amusant ;-)
Excellent, je m'interressais justement à REST et je redécouvre internet ici. Merci beaucoup pour cette explication ds plus plaisante. ça donne envie de s'y mettre.
C'est un peu dur à saisir mais je crois que ça fait lentement son chemin dans ma tête.
Est-ce que tu penses qu'une adoption unifiée du REST à travers le Web bénéficierait l'arrivée du Web 3.0?
Bien à toi,
Jérémy
Merci pour ces infos, REST m'interressait, mais je crois sincèrement que mon cerveau décroche ou que techniquement, j'ai encore des progès à faire ...
Merci pour ces infos détaillées mais je trouyve çà trop compliqué .... ou alors c'est moi qui ne suis plus :-(
Article très intéressant, mais celle reste quand même complexe à comprendre pas si évident que ça.
merci pour l'article,
je suis entrain de chercher comment généraliser REST aux applications desktop (desktop disribué)en implémentant le modèle MVC
pouvez vous m'aider?
Simple, efficace, merci !
Merci beaucoup pour cet article (et les liens associés).
Ça m'a permis de découvrir cette architecture (j'en avais souvent entendu parlé mais je n'avais jamais approfondi la question). Vivement la suite de l'article :)