davidbgk
/
larlet-fr-david

<!doctype html>
<html lang=fr>
<head>
  <!-- Always define the charset before the title -->
  <meta charset=utf-8>
  <title>★ Pour ne plus être en REST, comprendre cette architecture — Biologeek — David Larlet</title>
  <!-- Define a viewport to mobile devices to use - telling the browser to assume that the page is as wide as the device (width=device-width) and setting the initial page zoom level to be 1 (initial-scale=1.0) -->
  <meta name="viewport" content="width=device-width, initial-scale=1"/>
  <!-- Fake favicon, to avoid extra request to the server -->
  <link rel="icon" href="data:;base64,iVBORw0KGgo=">
  <link type="application/atom+xml" rel="alternate" title="Feed" href="/david/log/" />
  <link rel="manifest" href="/manifest.json">
  
  <link rel="stylesheet" href="/static/david/css/larlet-david-_J6Rv.css" data-instant-track />
  
  <noscript>
    <style type="text/css">
      /* Otherwise fonts are loaded by JS for faster initial rendering. See scripts at the bottom. */
      body {
        font-family: 'EquityTextB', serif;
      }
      h1, h2, h3, h4, h5, h6, time, nav a, nav a:link, nav a:visited {
        font-family: 'EquityCapsB', sans-serif;
        font-variant: normal;
      }
    </style>
  </noscript>
  
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://larlet.fr/david/biologeek/archives/20070413-pour-ne-plus-etre-en-rest-comprendre-cette-architecture">

</head>
<body>
  <div>
    
    <header>
      <nav>
        <p>
          <small>
            Je suis <a href="/david/" title="Profil public">David Larlet</a>, <a href="/david/pro/" title="Activité professionnelle">artisan</a> du web qui vous <a href="/david/pro/accompagnement/" title="Activité d’accompagnement">accompagne</a><span class="more-infos"> dans l’acquisition de savoirs pour concevoir des <a href="/david/pro/produits-essentiels/" title="Qu’est-ce qu’un produit essentiel ?">produits essentiels</a></span>. <span class="more-more-infos">Discutons ensemble d’une <a href="/david/pro/devis/" title="En savoir plus">non-demande de devis</a>.</span> Je partage ici mes <a href="/david/blog/" title="Expériences bienveillantes">réflexions</a> et <a href="/david/correspondances/2017/" title="Lettres hebdomadaires">correspondances</a>.
          </small>
        </p>
      </nav>
    </header>
    
    
  <section>
    <h1 property="schema:name">★ Pour ne plus être en REST, comprendre cette architecture</h1>
    <article typeof="schema:BlogPosting">
      <div property="schema:articleBody">
        <img src="/static/david/biologeek/images/logos/rest_softies.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />
        <p>Depuis quelques mois, <del>j'apprends</del> j'essaye d'apprendre <abbr title="Representational state transfer">REST</abbr> 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 <a href="http://softiesonrails.com/tags/rest">une série d'explications par Softies on Rails</a> se basant sur des exemples concrets. En voici la traduction chronologique.</p>

<h2>Comprendre les ressources</h2>

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

<p><strong>Si vous essayez de comprendre REST, cette série est faite pour vous.</strong></p>

<blockquote><p>Les experts en <abbr title="HyperText Transfer Protocol">HTTP</abbr>, <abbr title="HyperText Markup Language">HTML</abbr> 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 :-)</p></blockquote>

<h3>Premier point</h3>

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

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

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

<p>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&nbsp;:</p>

<ul>
<li><strong>une requête «&nbsp;GET »&nbsp;: récupère le contenu d'une ressource sur le web, la ressource est uniquement identifié par une <abbr title="Uniform Resource Locator">URL</abbr></strong>&nbsp;;</li>
<li><strong>une requête «&nbsp;POST »&nbsp;: envoie des données à une URL afin de créer une nouvelle ressource</strong>.</li>
</ul>

<h3>Deuxième point</h3>

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

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

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

<p>Je sais que c'est étrange au début. L'article sur Archimède n'est pas une page web&nbsp;? Non. J'ai demandé la représentation HTML d'une ressource appartenant à Wikipedia, une ressource pouvant être identifiée par l'<abbr title="Universal Resource Identifier">URI</abbr> «&nbsp;//fr.wikipedia.org/wiki/Archimède ». Wikipedia aurait pu choisir de représenter cette ressource de beaucoup de façons - avec un <acronym>PDF</abbr>, 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.</p>

<p>Un autre exemple&nbsp;: 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&nbsp;: 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. <strong>Une même ressource, plusieurs représentations.</strong></p>

<p>J'espère que c'est clair maintenant&nbsp;: 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.</p>

<h3>Troisième point</h3>

<p>Ok, maintenant que vous avez accepté le fait que <strong>le web est une gigantesque collection de ressources qui peuvent être servies de différentes manières</strong>, 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. <strong>Certaines ressources sont des collections d'autres ressources.</strong> 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.</p>

<p>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 (<em><abbr title="Note du traducteur">NdT</abbr>&nbsp;: bon normalement c'est <strong>crud</strong> pour <strong>c</strong>reate, <strong>r</strong>etrieve, <strong>u</strong>pdate et <strong>d</strong>elete</em>).</p>

<h2>Des millions d'API</h2>

<h3>Analyse orientée objet et design</h3>

<p>Si vous programmez en orienté objet depuis un certain temps, vous avez probablement appris à procéder de la façon suivante&nbsp;:</p>

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

<p>Ç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 <a href="http://fr.wikipedia.org/wiki/Remote_procedure_call">RPC</a>. 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 «&nbsp;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&nbsp;?</p>

<p>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&nbsp;: 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.</p>

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

<p>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&nbsp;? Je veux dire, comment feriez-vous autrement&nbsp;? 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).</p>

<h3>Et pour un million d'API&nbsp;?</h3>

<p>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&nbsp;: vous pouvez acheter de la musique, réserver des billets d'avion et avoir des vues satellites de votre maison.</p>

<p>Est-ce magique&nbsp;? 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 «&nbsp;Vérifier les vols ». Vous ne pouvez tout simplement pas développer un outil qui permette d'appeler des millions d'API différentes.</p>

<p><strong>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.</strong></p>

<h3>Une architecture orientée ressource</h3>

<p>D'après Wikipedia, <a href="http://fr.wikipedia.org/wiki/REST">REST</a> 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. <strong>En d'autres termes, chaque ressource aura la même API</strong>. Les méthodes clés de cette API autorisent chaque client à&nbsp;:</p>

<ul>
<li>avoir une vue en lecture seule de la ressource&nbsp;;</li>
<li>créer une nouvelle ressource&nbsp;;</li>
<li>mettre à jour les attributs d'une ressource&nbsp;;</li>
<li>supprimer une ressource.</li>
</ul>

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

<h2>Architecture RESTful</h2>

<h3>Nous sommes les dépôts</h3>

<p><strong>À partir de maintenant, pensez à votre application comme étant rien d'autre qu'un dépôt à ressources.</strong> Qu'est-ce qu'un dépôt&nbsp;? <a href="https://larlet.fr/david/biologeek/archives/20060707-installer-un-depot-subversion-sous-ubuntu/">Subversion</a> 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&nbsp;?</p>

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

<h3>Le pire exemple au monde</h3>

<p>Vous travaillez pour BiologeekAir, et vous devez développer leur infrastructure logicielle <em>from scratch</em>.</p>

<ul>
<li>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é.</li>
<li>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.</li>
<li>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.</li>
</ul>

<p>Ça semble être un projet alléchant, non&nbsp;? 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&nbsp;! 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&nbsp;! Oh, vous imaginez déjà les méthodes VolsPrévus.AnnulerVol() et Vol.Retard().</p>

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

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

<p><strong>Ne faites qu'identifier vos ressources.</strong></p>

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

<p>Comment les interfaces clients vont-elles accéder à chacune de ces ressources&nbsp;? Les URL ont été inventées pour ça. (Vous savez ce que signifie le L de <abbr title="Uniform Resource Locator">URL</abbr> n'est ce pas ?) Le «&nbsp;localisateur » de chaque ressource suit un pattern simple. Par exemple&nbsp;:</p>

<ul>
<li>/aeroports pour la liste des aéroports</li>
<li>/avions pour la liste des avions</li>
<li>/vols pour la liste des vols</li>
</ul>

<p>et&nbsp;:</p>

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

<h3>Quatre méthodes</h3>

<p>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&nbsp;:</p>

<ul>
<li><strong>GET&nbsp;: donnez moi une vue en lecture seule d'une instance d'une ressource depuis le dépôt.</strong></li>
<li><strong>POST&nbsp;: j'ai une nouvelle instance d'une ressource que je veux ajouter au dépôt.</strong></li>
<li><strong>PUT&nbsp;: je veux mettre à jour une ressource existante dans le dépôt.</strong></li>
<li><strong>DELETE&nbsp;: je veux supprimer une instance d'une ressource du dépôt.</strong></li>
</ul>

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

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

<h3>Appeler ces méthodes avec HTTP</h3>

<p>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&nbsp;? 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.</p>

<p>Vous pouvez aussi appeler la méthode POST à partir de votre navigateur - mais seulement s'il y a un formulaire &lt;form&gt; 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.</p>

<p><strong>Vous ne pouvez pas appeler PUT ou DELETE avec votre navigateur avec du HTML habituel</strong>. 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.</p>

<p>En résumé&nbsp;: <strong>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</strong>. Le client et le serveur doivent se mettre d'accord sur une convention à utiliser pour simuler les méthodes PUT et DELETE.</p>

<h3>On y est presque</h3>

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

<h2>Réactions du traducteur</h2>

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

<p>En ce qui concerne <strong>REST, sa principale limitation vient de la non standardisation des méthodes PUT et DELETE dans les navigateurs</strong>. 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 <strong>method="PUT"</strong> (ou DELETE) pour gérer les différentes possibilités. Espérons que de telles pratiques deviennent la norme de façon à ce que <strong>REST devienne réellement la référence en terme d'interopérabilité entre les différents services web</strong>.</p>

<h2>Ressources</h2>

<h3>En français</h3>

<ul>
<li><a href="http://www.la-grange.net/2005/05/rest/">Apprendre REST - un style d'architecture du Web</a></li>
<li><a href="http://www.clever-age.com/veille/clever-link/soap-vs.-rest-choisir-la-bonne-architecture-web-services.html">soap vs. rest&nbsp;: choisir la bonne architecture web services</a></li>
<li><a href="http://opikanoba.org/tr/fielding/rest/">Traduction du chapitre de la Thèse de Roy T. Fielding relatif à REST</a></li>
</ul>

<h3>En anglais</h3>

<ul>
<li><a href="http://tomayko.com/articles/2004/12/12/rest-to-my-wife">How I Explained REST to My Wife</a> (et <a href="http://www.pompage.net/pompe/comment-j-ai-explique-rest-a-ma-femme/">maintenant traduit en français</a>&nbsp;! Merci Karl).</li>
<li><a href="http://duncan-cragg.org/blog/tag/dialogue/">The REST Dialogues</a>&nbsp;: c'est un catégorie de son blog, il faut donc commencer par le dernier, c'est long mais ça en vaut la peine, surtout qu'il y a une <a href="http://addsimplicity.typepad.com/adding_simplicity_an_engi/2006/11/the_rest_dialog.html">vraie réponse d'un architecte eBay</a> qui a joué le jeu (il a répondu à d'autres aussi, généralement le lien est en commentaire).</li>
</ul>

<p>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 <strong>REST est plus qu'une alternative à SOAP</strong>&nbsp;!</p>

<p><strong>[edit]</strong>&nbsp;: un nouveau billet intitulé <a href="https://larlet.fr/david/biologeek/archives/20070629-architecture-orientee-ressource-pour-faire-des-services-web-restful/">L'architecture orientée ressource pour faire des services web RESTful</a> précise de nombreux points sur l'architecture REST non couverts dans ce billet.</p>
      </div>
    </article>
    <footer>
      <h6 property="schema:datePublished">— 13/04/2007</h6>
    </footer>
  </section>
  <section>
    <div>
      <h3>Articles peut-être en rapport</h3>
      <ul>
        <li><a href="/david/biologeek/archives/20101130-de-lopendata-au-linkeddata-exemple-de-nosdonneesfr/" title="Accès à ★ De l&#39;OpenData au LinkedData : exemple de nosdonnees.fr">★ De l&#39;OpenData au LinkedData : exemple de nosdonnees.fr</a></li>
        <li><a href="/david/biologeek/archives/20090526-django-roa-pour-une-architecture-orientee-ressources/" title="Accès à ★ Django-ROA, pour une architecture orientée ressources">★ Django-ROA, pour une architecture orientée ressources</a></li>
        <li><a href="/david/biologeek/archives/20081117-le-web-semantique-ou-limportance-des-donnees-liees/" title="Accès à ★ Le Web Sémantique ou l&#39;importance des données liées">★ Le Web Sémantique ou l&#39;importance des données liées</a></li>
      </ul>
    </div>
  </section>
  <section>
    <div id="comments">
      <h3>Commentaires</h3>
      
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Country</span> le <span class="comment-date" property="schema:commentTime">13/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci beaucoup pour cet article (et les liens associés).<br />
<br />
Ç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 :)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Thesa</span> le <span class="comment-date" property="schema:commentTime">13/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Wahou !<br />
<br />
Super article, merci beaucoup pour la traduction !</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">13/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Country et Thesa : merci.<br />
<br />
@Geoffrey : j'ai malencontreusement effacé ton commentaire en supprimant les spams, je suis vraiment vraiment désolé :/<br />
<br />
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 !<br />
<br />
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 ;-).</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">biou</span> le <span class="comment-date" property="schema:commentTime">14/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>si je peux me permettre, dans le paragraphe &quot;quatre méthodes&quot; je crois qu'il y a une inversion dans les descriptions de PUT et de POST.<br />
<a href="http://tools.ietf.org/html/rfc2616#section-9.5" title="http://tools.ietf.org/html/rfc2616#section-9.5" rel="nofollow">tools.ietf.org/html/rfc26...</a></p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">14/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@biou : je ne crois pas (cf. <a href="http://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol#M.C3.A9thodes" title="http://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol#M.C3.A9thodes" rel="nofollow">fr.wikipedia.org/wiki/Hyp...</a> )</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">gdo</span> le <span class="comment-date" property="schema:commentTime">15/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Super article bravo<br />
Maintenant il ne me reste (sans jeu de mot) plus qu'a reprendre mes programme ROR<br />
<br />
cordialement</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">karl</span> le <span class="comment-date" property="schema:commentTime">23/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>URIs, Addressability, and the use of HTTP GET and POST<br />
<a href="http://www.w3.org/2001/tag/doc/whenToUseGet.html" title="http://www.w3.org/2001/tag/doc/whenToUseGet.html" rel="nofollow">www.w3.org/2001/tag/doc/w...</a><br />
<br />
Notamment la checklist<br />
1.3 Quick Checklist for Choosing HTTP GET or POST</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">karl</span> le <span class="comment-date" property="schema:commentTime">23/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Un autre article tres interessant sur le sujet<br />
<br />
<a href="http://bitworking.org/news/125/REST-and-WS" title="http://bitworking.org/news/125/REST-and-WS" rel="nofollow">bitworking.org/news/125/R...</a></p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Jérémie Grodziski</span> le <span class="comment-date" property="schema:commentTime">28/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonjour David,<br />
<br />
Bravo pour cette traduction.<br />
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.<br />
En anglais : <a href="http://www.grodziski.com/blog/jcontent/en/Architecture/2006/11/01/REST-a-scalable-architecture.html" title="http://www.grodziski.com/blog/jcontent/en/Architecture/2006/11/01/REST-a-scalable-architecture.html" rel="nofollow">www.grodziski.com/blog/jc...</a><br />
Et en français :-) : <a href="http://www.grodziski.com/blog/jcontent/fr/Architecture/2006/11/01/REST-une-architecture-echelonnable.html" title="http://www.grodziski.com/blog/jcontent/fr/Architecture/2006/11/01/REST-une-architecture-echelonnable.html" rel="nofollow">www.grodziski.com/blog/jc...</a><br />
<br />
Jérémie.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">28/04/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci pour ces liens Jérémie qui complètent parfaitement ce billet.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">ThinkDRY Corp</span> le <span class="comment-date" property="schema:commentTime">14/05/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>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? <br />
</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">15/05/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Mmmh pas encore prêt à faire le grand saut mais qui sait, peut-être plus tard ? :-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Bader</span> le <span class="comment-date" property="schema:commentTime">25/06/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Tu peux peut-être rajouter ma courte présentation vidéo <a href="http://chamia.info/bader/archives/137" title="http://chamia.info/bader/archives/137" rel="nofollow">chamia.info/bader/archive...</a><br />
ainsi que le PDF qui va avec :<br />
<a href="http://journees.afpy.org/presentations/preston-ladjemi.pdf" title="http://journees.afpy.org/presentations/preston-ladjemi.pdf" rel="nofollow">journees.afpy.org/present...</a></p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Graouille</span> le <span class="comment-date" property="schema:commentTime">23/08/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Très bonne approche pour comprendre REST. C'est très clair. Merci.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Fred</span> le <span class="comment-date" property="schema:commentTime">26/12/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonjour<br />
<br />
J'ai traduit le chapitre 5 de la thèse de Roy. Fielding. Cela peut compléter la liste des ressources.<br />
<a href="http://opikanoba.org/tr/fielding/rest/" title="http://opikanoba.org/tr/fielding/rest/" rel="nofollow">opikanoba.org/tr/fielding...</a><br />
<br />
Fred</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">28/12/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Oh merci Fred ! J'ai ajouté le lien en ressource.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Bernard Notarianni</span> le <span class="comment-date" property="schema:commentTime">06/01/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Excellent article, autant dans la forme que le fond. <br />
<br />
Merci :-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Nicolas Martignole</span> le <span class="comment-date" property="schema:commentTime">01/02/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Article très clair et intéressant.<br />
Merci pour ta traduction<br />
<br />
Nicolas</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Azema</span> le <span class="comment-date" property="schema:commentTime">25/03/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci beaucoup pour ce billet,<br />
<br />
Cela m'a permit de mieux apercevoir Rest, même si c'est encore un peu flou dans ma tête.<br />
<br />
Je vais tenter de travailler un peu plus dessus, pour m'éclaircir les neurones.<br />
<br />
Merci encore et bon courage pour la suite avec Django.<br />
<br />
Azema.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">bea</span> le <span class="comment-date" property="schema:commentTime">06/04/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Je vais commencer à écrire une API REST en java, cet article m'a beaucoup aidé pour comprendre comment structurer mon projet.<br />
<br />
J'ai une question &quot;pratique&quot;, comment faire côté serveur  pour avoir autant d'URL? <br />
Je pensais utiliser des servlets mais comment faire avec une URL du type /XXX/&lt;user_id&gt;/getYYY ?<br />
Il faut analyser l'URL?<br />
<br />
Merci pour vos réponses.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">06/04/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@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 :-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">bea (RE)</span> le <span class="comment-date" property="schema:commentTime">06/04/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Tu parles d'arguments dans l'url.<br />
Je voudrais savoir pourquoi avoir des URLs du type  /XXX/&lt;user_id&gt;/getYYY plutôt que d'avoir une URL et un paramètre user_id.<br />
<br />
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.<br />
<br />
J'ai lu que c'était mieux de ne pas passer par des paramètres, pourquoi??<br />
<br />
merci<br />
</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">07/04/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>J'en ai pas mal parlé là : <a href="https://larlet.fr/david/biologeek/archives/20070629-architecture-orientee-ressource-pour-faire-des-services-web-restful/" title="https://larlet.fr/david/biologeek/archives/20070629-architecture-orientee-ressource-pour-faire-des-services-web-restful/" rel="nofollow">www.biologeek.com/journal...</a><br />
<br />
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).<br />
<br />
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).<br />
<br />
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.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Alex</span> le <span class="comment-date" property="schema:commentTime">08/04/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonjour,<br />
<br />
Pour avoir mis en place une architecture REST au sein d'une grande banque, voici quelques inconvénients et difficultés rencontrés :<br />
<br />
- 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)<br />
- 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 : <a href="http://www.fngtps.com/2007/06/flex-can-t-do-rest" title="http://www.fngtps.com/2007/06/flex-can-t-do-rest" rel="nofollow">www.fngtps.com/2007/06/fl...</a>)<br />
- 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 &quot;standard&quot; du côté serveur<br />
<br />
Alex.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">08/04/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci pour ce retour très intéressant Alex !<br />
<br />
Pour répondre à la problématique de mapping des ressources, je suis aussi confronté à ce problème et c'est pas toujours évident...<br />
<br />
Je trouve l'article de Joe Gregorio très intéressant à ce sujet :<br />
<a href="http://bitworking.org/news/201/RESTify-DayTrader" title="http://bitworking.org/news/201/RESTify-DayTrader" rel="nofollow">bitworking.org/news/201/R...</a><br />
<br />
Ç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.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">jc</span> le <span class="comment-date" property="schema:commentTime">09/04/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>le genre d'article a lire un soir ou la copine n'est pas dans le coin (pour éviter les conversation ressemblant à des monologue &quot;Hey j'ai encore lu un truc trop bien...tu m'écoute?&quot; mais plutot se dire intérieurement avec une certaine satisfaction &quot;Woa c trop cool encore un article qui vas m'en apprendre plus qu'a l'ecole&quot;)<br />
<br />
bref. nouveaux sur django, je m'en vais direct avaler l'article sur django/REST.<br />
<br />
Encore un petit mot pour dire merci sur la qualité de ce blog et sa volonté didactique éfficace (premier commentaire oblige ;) )</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">mamo</span> le <span class="comment-date" property="schema:commentTime">18/04/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci, Super article sympa sur REST... </p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Mathieu</span> le <span class="comment-date" property="schema:commentTime">19/12/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonsoir,</p>

<p>L&#39;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&#39;on en croit ce document <a href="http://tools.ietf.org/html/rfc2616#page-54">http://tools.ietf.org/html/rfc2616#page-54</a> , ce serai plutot:</p>

<p>PUT: créer ou modifier la ressource a tel uri, par exemple:<br />PUT /user/mathieu<br />avec dans le body: <br />&lt;user&gt;<br /> &lt;prenom&gt;mathieu&lt;/prenom&gt;<br /> &lt;nom&gt;.....&lt;/nom&gt;<br /> ....<br />&lt;/user&gt;</p>

<p>alors que POST ne signifie pas nécéssairement qu&#39;une ressource sera créer. dans l&#39;application sur laquelle je travaille, on essai d&#39;utiliser POST, seulement quand on ne peux pas utiliser PUT, en général, lorsque l&#39;on ne connais pas à l&#39;avance l&#39;uri qui permettra d&#39;identifier la ressource (par exemple si l&#39;identifiant est un id auto incrémenté de base de donnée)</p>

<p>Cordialement, Mathieu.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">22/12/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Mathieu : je suis tout à fait d&#39;accord, et c&#39;est ce que je précise dans un billet suivant (qui lui n&#39;est pas une traduction) :<br /><a href="https://larlet.fr/david/biologeek/archives/20070629-architecture-orientee-ressource-pour-faire-des-services-web-restful/">https://larlet.fr/david/biologeek/archives/20070629-architecture-orientee-ressource-pour-faire-des-services-web-restful/</a></p>

<p>Cela dit, il est assez rare de connaître à partir du client les contraintes appliquées sur le serveur, comme tu le précises.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Michel Baily</span> le <span class="comment-date" property="schema:commentTime">05/02/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonjour,</p>

<p>Merci pour cette explication claire.<br />Je suis également dans une situation &quot;J&#39;apprends Ruby + RoR + Le Web dévelopmment+ Ajax + ...&quot;<br />Donc beaucoup de questions se posent à moi.<br />Notamment par rapport aux listes de ressources comme dans l&#39;exemple<br />/aeroports pour la liste des aéroports<br />/aeroports/orly  pour orly</p>

<p>Comment implémente-t-on la notion de filtre ?<br />Imaginons que je souhaite une liste des aéroports de France. Mon Url serait<br />/aeroports/france<br />Comment mon code va-t-il pouvoir identifier que france est une (sous)liste alors que orly est une resource ?<br />( Je voudrais évidement éviter de devoir demander<br />/aeroports/france/orly )</p>

<p>Désolé si la question peut paraitre triviale à certains ;-)</p>

<p>Michel</p>

<p></p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">06/02/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Salut Michel,</p>

<p>Je dirais que tout dépend si le filtre est assimilable à une collection lui-même.</p>

<p>Par exemple, si on veut juste pouvoir filtrer les aéroports en France, on peut passer les arguments en GET :<br />/aeroports/?country=France<br />Cette page listera les ressources (dont un lien vers Orly) qui correspondent à des aéroports filtrés pour le pays France.</p>

<p>Maintenant c&#39;est souvent au cas par cas, selon l&#39;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&#39;avoir la notion de filtrage par lieu directement dans l&#39;URL. Il n&#39;y a pas de réponse dans l&#39;absolu :-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Vincent Boniakos</span> le <span class="comment-date" property="schema:commentTime">24/02/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Salut Michel,<br />J&#39;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.<br />Le principe est le suivant :<br />1. Chaque URI possède son controller.<br />Lorsque tu tapes <a href="http://www.monsite.com/aeroports">www.monsite.com/aeroports</a> un controller nommé &quot;aeroport_list_controller&quot; va s&#39;occuper de ta requête : par exemple afficher la liste des aéroports. De même si tapes <a href="http://www.monsite.com/aeroports/orly">www.monsite.com/aeroports/orly</a> un controller que l&#39;on va appelé &quot;aeroport_show_controller&quot; s&#39;occupera de ta requête, et affichera la liste des avions à orly.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Vincent Boniakos</span> le <span class="comment-date" property="schema:commentTime">24/02/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>(Suite)<br />2.Chaque controller possède deux comportement.<br />Le premier est décrit en 1., le second est de rediriger vers le controller correspondant à ta requête.<br />Un exemple : je saisie l&#39;url <a href="http://www.monsite.com/aeroports/orly/vols/451">www.monsite.com/aeroports/orly/vols/451</a>. Le premier controller en jeu est &quot;aeroport_list_controller&quot;, qui me redirige vers &quot;aeroport_show_controller&quot;. &quot;aeroport_show_controller&quot; me redirige vers &quot;vols_list_controller&quot;.<br />&quot;vols_list_controller&quot; me redirige ensuite vers &quot;vols_show_controller&quot; qui affichera le vol 451 au départ d&#39;orly !<br />3.Chaque controller connait le contexte dans lequel il est appelé, par imbriquation. Ainsi lorsque je saisis aeroports/orly/vols/451, &quot;vols_show_controller&quot; sait que je souhaite afficher le vol 451 au départ d&#39;orly.<br />Enfin c&#39;est à toi d&#39;implémenter les méthodes GET, POST, PUT et DELETE dans chaque controller.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">guigui</span> le <span class="comment-date" property="schema:commentTime">14/06/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonjour, <br />cet article est très intéressant, il m&#39;a permis de mieux comprendre REST. <br />Pour un TP j&#39;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, ...)  ?</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">LTC</span> le <span class="comment-date" property="schema:commentTime">21/08/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci pour l&#39;article... Je dois développer sous une architecture REST et ça me semble moins flou.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Dominique Rabeuf</span> le <span class="comment-date" property="schema:commentTime">11/10/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Et maintenant comment faire avec xmpp ? Il n&#39;y a pas les méthodes de http ? C&#39;est pas grave, parce que peut importe la manière de désigner, ce qui compte c&#39;est la ressource et ce qu&#39;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</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Ronald</span> le <span class="comment-date" property="schema:commentTime">19/11/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Superbe article au total, Merci</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Bilal</span> le <span class="comment-date" property="schema:commentTime">30/03/2010</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci pour cette introduction pratique à REST</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">mélanie</span> le <span class="comment-date" property="schema:commentTime">22/05/2010</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>C&#39;est sympa l&#39;approche pour la compréhension de post et de rest.</p>

<p>Comme quoi on peu apprendre en s&#39;amusant ;-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Jérémy</span> le <span class="comment-date" property="schema:commentTime">08/09/2010</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Excellent, je m&#39;interressais justement à REST et je redécouvre internet ici. Merci beaucoup pour cette explication ds plus plaisante. ça donne envie de s&#39;y mettre.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Jeremy - Stratège Web</span> le <span class="comment-date" property="schema:commentTime">05/07/2011</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>C&#39;est un peu dur à saisir mais je crois que ça fait lentement son chemin dans ma tête.</p>

<p>Est-ce que tu penses qu&#39;une adoption unifiée du REST à travers le Web bénéficierait l&#39;arrivée du Web 3.0?</p>

<p>Bien à toi,<br />Jérémy</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Philippe</span> le <span class="comment-date" property="schema:commentTime">17/08/2011</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci pour ces infos, REST m&#39;interressait, mais je crois sincèrement que mon cerveau décroche ou que techniquement, j&#39;ai encore des progès à faire ...</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Abuzz</span> le <span class="comment-date" property="schema:commentTime">05/10/2011</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci pour ces infos détaillées mais je trouyve çà trop compliqué .... ou alors c&#39;est moi qui ne suis plus :-(</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Gerard</span> le <span class="comment-date" property="schema:commentTime">09/11/2011</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Article très intéressant, mais celle reste quand même complexe à comprendre pas si évident que ça.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">kaouther</span> le <span class="comment-date" property="schema:commentTime">26/12/2011</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>merci pour l&#39;article,<br />je suis entrain de chercher comment généraliser REST aux applications desktop (desktop disribué)en implémentant le modèle MVC <br />pouvez vous m&#39;aider?</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Vincent François</span> le <span class="comment-date" property="schema:commentTime">09/01/2012</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Simple, efficace, merci !</p>
    </div>
</div>

    </div>
  </section>

    
    <footer>
      <nav>
        <p>
          <small>
            Je réponds quasiment toujours aux <a href="m&#x61;ilto:d&#x61;vid%40l&#x61;rlet&#46;fr" title="Envoyer un email">emails</a> (<a href="/david/signature/" title="Ma signature actuelle avec possibilité de chiffrement">signés</a>) et vous pouvez me rencontrer à Montréal. <span class="more-infos">N’hésitez pas à <a href="/david/log/" title="Être tenu informé des mises à jour">vous abonner</a> pour être tenu informé des publications récentes.</span>
          </small>
        </p>
      </nav>
    </footer>
    
  </div>
  
  <script src="/static/david/js/larlet-david-3ee43f.js" data-no-instant></script>
  
  <script data-no-instant>InstantClick.init()</script>
  
</body>
</html>