★ Pour ne plus être en REST, comprendre cette architecture

vignette

Depuis quelques mois, j'apprends j'essaye d'apprendre REST et j'ai lu de nombreuses pages sans pour autant trouver d'explication simple, à la portée de tous. Du coup quand j'essaye d'expliquer les mécanismes et les avantages professionnellement, c'est pas toujours convaincant... et je voulais justement écrire un petit billet pour mettre tout ça au clair. Et puis je suis récemment tombé sur une série d'explications par Softies on Rails se basant sur des exemples concrets. En voici la traduction chronologique.

Comprendre les ressources

D'une certaine manière, apprendre REST fut très difficile pour moi. Je ne sais pas vraiment pourquoi. Peut-être car j'ai passé une bonne partie de ma vie à développer des applications client et non des applications web. Peut-être est-ce parce que (à lire rapidement) j'ai commencé à développer pour le web tout en apprenant Ruby tout en apprenant Rails et que j'ai ensuite été à RailsConf et tout le monde était excité par REST et j'approuvais pour ne pas passer pour un imbécile mais honnêtement je ne savais pas de quoi il retournait...

Si vous essayez de comprendre REST, cette série est faite pour vous.

Les experts en HTTP, HTML et REST pourraient chercher la petite bête avec ma terminologie simplifiée me permettant d'aller droit au but. Si c'est votre cas, je ne veux pas en entendre parler, car cette série ne vous est pas destinée de toute façon :-)

Premier point

Commençons par le commencement. Comment fonctionne un navigateur ? Avant d'essayer de développer des sites avec Rails, je pensais que ça marchait ainsi :

  • je tape une url dans la barre d'adresse ou je clic sur un lien ;
  • le navigateur fait une « requête http » (quoi que cela puisse signifier) et obtient du code HTML en réponse ;
  • le navigateur interprète ce HTML pour afficher la page.

Et c'est à peu près tout. Et je ne me suis jamais demandé comment les formulaires fonctionnaient. Je me disais juste que ça devait être une variante de la précédente description.

En réalité, le protocole HTTP décrit les instructions détaillées de la façon dont un navigateur doit envoyer ses requêtes au serveur. HTTP est totalement différent du HTML, qui est le langage choisit pour représenter le contenu d'une page. HTTP permet au navigateur de récupérer divers types d'informations à partir du serveur, dont la simple récupération d'une page HTML ou la soumission d'un formulaire. En fait, HTTP permet d'effectuer huit types de requêtes différentes sur le serveur. Les deux requêtes les plus connues sont les suivantes :

  • une requête « GET » : récupère le contenu d'une ressource sur le web, la ressource est uniquement identifié par une URL ;
  • une requête « POST » : envoie des données à une URL afin de créer une nouvelle ressource.

Deuxième point

Remarquez comme j'ai glissé le mot « ressource » alors que vous ne l'attendiez pas. Ça a été mon premier mal de tête lorsque j'ai essayé de comprendre REST : penser au web comme un ensemble de ressources, pas de « pages web ». Qu'est-ce que je veux dire par là ?

Hier, je suis allé sur amazon.com et j'ai consulter quelques produit que je voudrais acheter. J'ai aussi lu quelques articles de Wikipedia. J'ai parcouru quelques news de TechCrunch et j'ai ensuite vérifier les scores de D1 pour constater à quel point Lyon est loin devant.

Si vous voulez comprendre REST, vous devez arrêter de penser à tout ça en termes de pages web. Prenons l'exemple d'un article de Wikipedia. Ce n'est pas seulement une page web, c'est une ressource - dans notre exemple un biographie d'Archimède. J'utilise un navigateur web pour accéder à cette ressource, le navigateur récupère donc une représentation HTML de cette ressource, car afficher du HTML est la seule possibilité de représentation de ces ressources par un navigateur.

Je sais que c'est étrange au début. L'article sur Archimède n'est pas une page web ? Non. J'ai demandé la représentation HTML d'une ressource appartenant à Wikipedia, une ressource pouvant être identifiée par l'URI « //fr.wikipedia.org/wiki/Archimède ». Wikipedia aurait pu choisir de représenter cette ressource de beaucoup de façons - avec un PDF, ou peut-être une image .jpg. C'est même peut-être déjà possible. Mais Firefox utilise une requête GET qui spécifie que cette ressource doit être obtenue à partir du serveur sous forme de HTML, donc c'est ce que j'ai.

Un autre exemple : ma réservation d'avion est une ressource détenue par Air France. Ils me permettent d'accéder à cette ressource de diverses manières : via une page HTML, mais ils peuvent aussi envoyer les informations de ma réservation sur mon téléphone portable. Ou ils peuvent me l'envoyer par mail en texte brut. Ou je peux les appeler avec un outil obsolète et ils vont me le dire de vive voix. Une même ressource, plusieurs représentations.

J'espère que c'est clair maintenant : ma réservation d'avion n'est pas qu'une page web. C'est une vraie ressource qui (heureusement pour moi) peut être affichée en HTML lorsque je le désire, et je peux utilise mon navigateur pour demander cette représentation et l'afficher sur mon écran.

Troisième point

Ok, maintenant que vous avez accepté le fait que le web est une gigantesque collection de ressources qui peuvent être servies de différentes manières, et qu'un affichage HTML est juste l'une d'entre elles, il y a maintenant un dernier concept que je souhaite aborder. Les ressources ne sont pas uniquement des simples articles biographiques, ou des réservations d'avions, ou des résultats sportifs. Certaines ressources sont des collections d'autres ressources. Une liste de vacances peut être une ressource. Une liste d'amis peut être une ressource. Une série de billets de blog peut être une ressource.

Maintenant que vous avez compris ce que sont les ressources, nous allons maintenant nous intéresser à la façon dont HTTP permet la création, la récupération, la mise à jour et la suppression des ressources (NdT : bon normalement c'est crud pour create, retrieve, update et delete).

Des millions d'API

Analyse orientée objet et design

Si vous programmez en orienté objet depuis un certain temps, vous avez probablement appris à procéder de la façon suivante :

  • écrire une description de votre problématique - ce que votre programme est censé faire.
  • les noms sont vos classes.
  • les verbes sont les méthodes de vos classes.
  • permettre à vos noms d'appeler les méthodes d'autres noms pour qu'ils accomplissent des tâches.

Ça semble bon. C'est ce que je fais en programmation depuis un moment déjà. Ce type de programmation par nom-verbe est souvent appelé style RPC. Je ne sais pas en quoi c'est proche de l'accès à distance mais je sais juste que le style RPC est la façon « classique » de développer des logiciels avec de l'orienté objet. C'est une très bonne manière pour développer des logiciels mais ce n'est pas la façon dont le web a été pensé. Pourquoi ça ?

Imaginez-vous en 1992 (ou juste avant que le web soit tel que vous le connaissez aujourd'hui). Et supposez 3 équipes différentes qui développent 3 logiciels : un pour acheter des livres, un pour acheter des billets d'avion et un autre qui permet d'obtenir des photographies aériennes de n'importe quelle distance de la Terre. Elles suivent toutes les 3 les techniques de modélisation orientée objet classiques dont nous avons parlé pour développer leurs applications. Et pensant qu'un tiers voudra probablement un jour s'interfacer avec leur logiciel, elles vont aussi implémenter leurs propres API.

Maintenant supposons que ce soit votre boulot d'écrire un outil qui soit une interface de ces 3 applications.

Ugh. Vous allez devoir apprendre 3 API différentes. Et je parie que vous voudriez des boutons qui correspondent directement aux méthodes que vous appelez pour chaque API. Ça semble logique, non ? Je veux dire, comment feriez-vous autrement ? Ok, on ne parle que de 3 API et vous connaissez de bon ouvrages qui ont des design patterns qui vont vous permettre de réduire cette complexité (et de rester aimable avec vos collègues par la même occasion).

Et pour un million d'API ?

Revenons au navigateur. Lorsque vous l'installez sur votre ordinateur, il n'a aucune idée des sites que vous allez vouloir visiter. Par contre, il peut communiquer avec n'importe lequel de ces sites. Mais pas seulement, vous pouvez réaliser des actions sur ces sites : vous pouvez acheter de la musique, réserver des billets d'avion et avoir des vues satellites de votre maison.

Est-ce magique ? Réfléchissez un moment à l'impossibilité d'une telle approche si chaque site avait sa propre API. Pour acheter un livre sur Amazon, le navigateur aurait dû savoir appeler la méthode Amazon.Acheter(). Et il aurait dû appeler la méthode AirFrance.VérifierVols() lorsque j'ai cliqué sur le bouton « Vérifier les vols ». Vous ne pouvez tout simplement pas développer un outil qui permette d'appeler des millions d'API différentes.

C'est la raison pour laquelle le web n'a pas été designé avec une architecture RPC. Il a été designé avec une architecture REST.

Une architecture orientée ressource

D'après Wikipedia, REST signifie Representational State Transfer. Bon... peu importe. Cela signifie simplement qu'en lieu et place des noms avec des verbes arbitraires associés, chaque nom (que nous appellerons maintenant ressource) aura le même nombre fini de verbes. En d'autres termes, chaque ressource aura la même API. Les méthodes clés de cette API autorisent chaque client à :

  • avoir une vue en lecture seule de la ressource ;
  • créer une nouvelle ressource ;
  • mettre à jour les attributs d'une ressource ;
  • supprimer une ressource.

Attendez ! Laquelle de ces méthode permet « d'acheter ce livre » ? Laquelle permet de « chercher les vols entre Paris et Marseille mardi prochain » ? Laquelle me permet de zoomer d'une ville à une rue sur une carte ? Et laquelle permet à un utilisateur de se connecter à un site ?

Architecture RESTful

Nous sommes les dépôts

À partir de maintenant, pensez à votre application comme étant rien d'autre qu'un dépôt à ressources. Qu'est-ce qu'un dépôt ? Subversion est un bon exemple de dépôt de code source. MySQL est un dépôt de données relationnelles. Vous pensez à d'autres exemples ?

Pour le moment, j'ai juste besoin de prendre un exemple de dépôt que l'on puisse utiliser dans la suite de ce billet.

Le pire exemple au monde

Vous travaillez pour BiologeekAir, et vous devez développer leur infrastructure logicielle from scratch.

  • Vous avez besoin d'un client riche, une interface permettant de saisir les informations de vol. Un vol est juste la définition d'un avion allant d'une ville à une autre à un moment donné.
  • Vous voulez une interface web pour les employés de l'aéroport. Vous voulez que les passagers puissent vérifier le statut du vol à partir de leur téléphone portable.
  • Et votre boss veut que vous créiez une belle API basée sur XML que les tiers pourront utiliser pour mettre à jour les gigantesques affichages de départs et d'arrivées de l'aéroport.

Ça semble être un projet alléchant, non ? Souvenez-vous de la première partie, nous avons décrit une architecture orientée objet traditionnelle et la façon dont il faut commencer en décrivant votre problème pour identifier les noms (qui deviendront vos objets) et les verbes (qui deviendront les méthodes). Imaginez juste le nombre de design patterns géniaux que vous allez pouvoir mettre en œuvre ! Vous ne pouvez plus résister à l'envie de dessiner un énorme diagramme UML au tableau et d'enchaîner avec quelques diagrammes d'interactions ! Oh, vous imaginez déjà les méthodes VolsPrévus.AnnulerVol() et Vol.Retard().

Désolé David. Depuis que vous utilisez REST, une grande partie de votre design est déjà fait pour vous ! En fait, la seule chose qu'il vous reste à faire est d'identifier vos ressources.

Laissez-moi le répéter, au cas où vous ne m'auriez pas entendu avec le raffut que font vos marqueurs effaçables, car c'est vraiment important.

Ne faites qu'identifier vos ressources.

Dans notre exemple, je peux rapidement identifier quelques noms clés : avions, aéroports et vols. Je vais probablement en trouver davantage ensuite mais c'est déjà un bon début.

Comment les interfaces clients vont-elles accéder à chacune de ces ressources ? Les URL ont été inventées pour ça. (Vous savez ce que signifie le L de URL n'est ce pas ?) Le « localisateur » de chaque ressource suit un pattern simple. Par exemple :

  • /aeroports pour la liste des aéroports
  • /avions pour la liste des avions
  • /vols pour la liste des vols

et :

  • /aeroports/ory pour Paris Orly
  • /avions/ZJ3543 pour l'avion identifié par le numéro de série ZJ3543
  • /vols/451 pour le vol #451

Quatre méthodes

Ok, une fois vos ressources identifiées, REST définie les 4 méthodes (ou verbes en langage HTTP) que chacune de vos ressources peuvent implémenter :

  • GET : donnez moi une vue en lecture seule d'une instance d'une ressource depuis le dépôt.
  • POST : j'ai une nouvelle instance d'une ressource que je veux ajouter au dépôt.
  • PUT : je veux mettre à jour une ressource existante dans le dépôt.
  • DELETE : je veux supprimer une instance d'une ressource du dépôt.

Ça vous semble familier ? Avec Subversion, GET est similaire aux commandes « checkout » ou « update ». POST correspond à la commande « add » et DELETE à « delete ». Dans l'exemple avec MySQL, GET revient à faire un SELECT, POST un INSERT, PUT est semblable à UPDATE et DELETE, et bien, DELETE.

Wow. Nous avons nos ressources et nous avons nos méthodes. On peut arrêter ici le design et commencer l'implémentation.

Appeler ces méthodes avec HTTP

Les applications web utilisent HTTP pour permettre au serveur et au client de communiquer ensemble. On peut maintenant préciser la première partie qui était restée assez floue. Que se passe-t-il vraiment lorsque vous tapez une adresse dans votre navigateur ? Le navigateur met en forme un message HTTP pour appeler la méthode GET de la ressource identifiée par l'URL que vous lui avez fourni.

Vous pouvez aussi appeler la méthode POST à partir de votre navigateur - mais seulement s'il y a un formulaire <form> sur la page. (Ok, pas exactement grâce à AJAX mais oublions pour le moment). Les formulaires peuvent envoyer des données à une URL particulière. Lorsque vous soumettez un formulaire, le navigateur appelle la méthode POST, passant l'URL ainsi que certaines données représentant la ressource qu'il doit ajouter ou modifier.

Vous ne pouvez pas appeler PUT ou DELETE avec votre navigateur avec du HTML habituel. Ce qui est bien malheureux. Bien que chaque serveur HTTP dans le monde sache gérer les appels aux méthodes PUT et DELETE, il n'y a pas de procédure standardisée pour faire ces appels avec du HTML. Vous devez inventer votre propre façon de faire pour signaler au serveur que vous essayer de faire des appels à PUT ou DELETE.

En résumé : vous pouvez faire correspondre votre API REST avec les verbes HTTP mais il n'y a aucun tag HTML qui permette de faire des appels à PUT ou DELETE. Le client et le serveur doivent se mettre d'accord sur une convention à utiliser pour simuler les méthodes PUT et DELETE.

On y est presque

Maintenant que notre design est au point, nous l'implémenterons prochainement avec Rails Django ;-).

Réactions du traducteur

Bon vous l'aurez compris, les prochains billets ne seront pas des traductions d'exemples d'implémentation avec Ruby on Rails mais des articles originaux pour voir ce qu'il est possible de faire avec Django. Plusieurs projets ont vu le jour et vont tenter de s'unifier pour arriver à une solution cohérente et facilement intégrable. Bon accessoirement, j'aimerais bien mettre en place professionnellement une telle architecture donc ça m'intéresse beaucoup.

En ce qui concerne REST, sa principale limitation vient de la non standardisation des méthodes PUT et DELETE dans les navigateurs. Je pense que c'est l'un des freins actuel à son adoption face à d'autres alternatives. Néanmoins, la possibilité de mettre en place du REST facilement côté serveur avec la dernière version de Ruby on Rails va, je l'espère, un peu démocratiser tout ça. Corrigez-moi si je me trompe mais RoR a choisi de placer une champ caché avec l'attribut method="PUT" (ou DELETE) pour gérer les différentes possibilités. Espérons que de telles pratiques deviennent la norme de façon à ce que REST devienne réellement la référence en terme d'interopérabilité entre les différents services web.

Ressources

En français

En anglais

Je n'en mets pas plus car vous allez très vite être submergé de liens, c'est juste pour vous mettre en appétit, j'espère que vous êtes maintenant convaincu que REST est plus qu'une alternative à SOAP !

[edit] : un nouveau billet intitulé L'architecture orientée ressource pour faire des services web RESTful précise de nombreux points sur l'architecture REST non couverts dans ce billet.

— 13/04/2007

Articles peut-être en rapport

Commentaires

Country le 13/04/2007 :

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 :)

Thesa le 13/04/2007 :

Wahou !

Super article, merci beaucoup pour la traduction !

David, biologeek le 13/04/2007 :

@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 ;-).

biou le 14/04/2007 :

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...

David, biologeek le 14/04/2007 :

@biou : je ne crois pas (cf. fr.wikipedia.org/wiki/Hyp... )

gdo le 15/04/2007 :

Super article bravo
Maintenant il ne me reste (sans jeu de mot) plus qu'a reprendre mes programme ROR

cordialement

karl le 23/04/2007 :

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

karl le 23/04/2007 :

Un autre article tres interessant sur le sujet

bitworking.org/news/125/R...

Jérémie Grodziski le 28/04/2007 :

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.

David, biologeek le 28/04/2007 :

Merci pour ces liens Jérémie qui complètent parfaitement ce billet.

ThinkDRY Corp le 14/05/2007 :

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?

David, biologeek le 15/05/2007 :

Mmmh pas encore prêt à faire le grand saut mais qui sait, peut-être plus tard ? :-)

Bader le 25/06/2007 :

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...

Graouille le 23/08/2007 :

Très bonne approche pour comprendre REST. C'est très clair. Merci.

Fred le 26/12/2007 :

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

David, biologeek le 28/12/2007 :

Oh merci Fred ! J'ai ajouté le lien en ressource.

Bernard Notarianni le 06/01/2008 :

Excellent article, autant dans la forme que le fond.

Merci :-)

Nicolas Martignole le 01/02/2008 :

Article très clair et intéressant.
Merci pour ta traduction

Nicolas

Azema le 25/03/2008 :

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.

bea le 06/04/2008 :

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.

David, biologeek le 06/04/2008 :

@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 :-)

bea (RE) le 06/04/2008 :

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

David, biologeek le 07/04/2008 :

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.

Alex le 08/04/2008 :

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.

David, biologeek le 08/04/2008 :

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.

jc le 09/04/2008 :

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 ;) )

mamo le 18/04/2008 :

Merci, Super article sympa sur REST...

Mathieu le 19/12/2008 :

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.

David, biologeek le 22/12/2008 :

@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.

Michel Baily le 05/02/2009 :

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

David, biologeek le 06/02/2009 :

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 :-)

Vincent Boniakos le 24/02/2009 :

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.

Vincent Boniakos le 24/02/2009 :

(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.

guigui le 14/06/2009 :

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, ...) ?

LTC le 21/08/2009 :

Merci pour l'article... Je dois développer sous une architecture REST et ça me semble moins flou.

Dominique Rabeuf le 11/10/2009 :

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

Ronald le 19/11/2009 :

Superbe article au total, Merci

Bilal le 30/03/2010 :

Merci pour cette introduction pratique à REST

mélanie le 22/05/2010 :

C'est sympa l'approche pour la compréhension de post et de rest.

Comme quoi on peu apprendre en s'amusant ;-)

Jérémy le 08/09/2010 :

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.

Jeremy - Stratège Web le 05/07/2011 :

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

Philippe le 17/08/2011 :

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 ...

Abuzz le 05/10/2011 :

Merci pour ces infos détaillées mais je trouyve çà trop compliqué .... ou alors c'est moi qui ne suis plus :-(

Gerard le 09/11/2011 :

Article très intéressant, mais celle reste quand même complexe à comprendre pas si évident que ça.

kaouther le 26/12/2011 :

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?

Vincent François le 09/01/2012 :

Simple, efficace, merci !