davidbgk
/
larlet-fr-david

<!doctype html>
<html lang=fr>
<head>
  <!-- Always define the charset before the title -->
  <meta charset=utf-8>
  <title>Une solution pour faciliter la conception d&#39;applications web RESTful avec Django — 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/20070807-une-solution-pour-faciliter-la-conception-d-applications-web-restful-avec-django">

</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">Une solution pour faciliter la conception d&#39;applications web RESTful avec Django</h1>
    <article typeof="schema:BlogPosting">
      <div property="schema:articleBody">
        <img src="/static/david/biologeek/images/logos/django.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />
        <p>Voila la solution à laquelle je suis arrivé après avoir testé les solutions existantes&nbsp;: <a href="http://code.google.com/p/djangocollection/">django collection</a>, <a href="http://code.google.com/p/django-crudapi/">django crudapi</a> et <a href="http://code.google.com/p/django-restful-model-views/">django restful model views</a>. J'attends beaucoup du <a href="http://code.google.com/p/django-rest-interface/"><abbr title="Google Summer of Code">GSoC</abbr> consacré à l'inclusion native de REST dans Django</a> et les choses vont dans le bon sens de ce côté là mais j'avais besoin d'une solution <em>maintenant</em>. Enfin notez bien le <strong>une</strong> dans le titre qui est très important, il y a énormément d'interprétations de l'architecture <abbr title="Representational State Transfer">REST</abbr>, cette implémentation essaye de s'inspirer de celle définie dans le livre RESTful Web Services&nbsp;: l'<a href="https://larlet.fr/david/biologeek/archives/20070629-architecture-orientee-ressource-pour-faire-des-services-web-restful/">architecture orientée ressource (ROA)</a>.</p>

<h2>Objectif ressource</h2>

<p><strong>Le but principal de cette solution est de simplifier le développement de l'accès à vos ressources. Pour cela une classe générique s'occupe de dispatcher votre requête dans la bonne méthode en fonction du verbe HTTP</strong>. Dans le cas d'une application authentifiée, vous pouvez contrôler les accès aux ressources en fonction des permissions de Django. Enfin la notion d'annulation  a été incluse car j'apprécie cette approche (cf. en fin de billet).</p>

<h2>Préparons le terrain</h2>

<p>La première chose à faire est d'utiliser le middleware permettant d'effectuer de fausses requêtes HTTP PUT et DELETE à partir d'un navigateur (ce qui n'est pas possible actuellement)&nbsp;:</p>

<pre>_SUPPORTED_TRANSFORMS = ['PUT', 'DELETE']
_MIDDLEWARE_KEY = '_method'

class HttpMethodsMiddleware(object):
    def process_request(self, request):
        if request.POST and _MIDDLEWARE_KEY in request.POST:
            if request.POST[_MIDDLEWARE_KEY].upper() in _SUPPORTED_TRANSFORMS:
                request.method = request.POST[_MIDDLEWARE_KEY].upper()
        return None</pre>

<p>Cela permet de passer de convertir le verbe POST en PUT ou DELETE en fonction de l'argument <strong>_method</strong> (généralement caché dans un formulaire).</p>

<p>Les permissions par défaut de Django n'incluent pas la notion d'affichage, il est donc nécessaire d'ajouter cette permission à tous vos modèles. Comme tout ce qui est long et fastidieux avec Django, il existe une solution élégante utilisant les <em>signals</em> pour automatiser tout ça&nbsp;:</p>

<pre>def create_retrieve_permissions(app, created_models, verbosity):
    app_models = get_models(app)
    for klass in app_models:
        ctype = ContentType.objects.get_for_model(klass)
        codename = _get_permission_codename('retrieve', klass._meta)
        name = 'Can %s %s' % ('retrieve', klass._meta.verbose_name)
        p, created = Permission.objects.get_or_create(codename=codename,
            content_type__pk=ctype.id,
            defaults={'name': name, 'content_type': ctype})
        if created and verbosity &gt;= 2:
            print "Adding permission '%s'" % p

dispatcher.connect(create_retrieve_permissions, signal=signals.post_syncdb)</pre>

<p>La permission est créée à chaque fin de <strong>syncdb</strong> pour l'ensemble des modèles existants.</p>

<h2>Passons aux choses sérieuses</h2>

<p>Je ne vais pas trop coller de code ici, vous le retrouverez commenté dans le paquet. Je vais plus expliquer les concepts pour comprendre comment l'utiliser.</p>

<p>Nous allons implémenter une todo liste basique permettant d'exploiter les différentes fonctionnalités développées. Nos URI devront avoir le modèle suivant (conformément au <a href="http://bitworking.org/news/wsgicollection">design définit par Joe Gregorio</a>)&nbsp;:</p>

<pre>/{model}/{id};{noun}</pre>

<p>Vous savez qu'une URL se construit avec Django de la façon suivante&nbsp;:</p>

<pre>urlpatterns = patterns('',
    (expression régulière, fonction de la vue),
)</pre>

<p>L'idée ici est de passer non pas une fonction à votre pattern mais une classe, ou plus précisément une instance de classe. En instanciant cette classe, vous allez appeler la méthode __call__ de la classe (ça c'est du python) qui va faire tout le travail de redirection vers la bonne méthode de la classe en fonction du verbe HTTP de la requête.</p>

<p>On va donc avoir une définition des URL qui va ressembler à ça&nbsp;:</p>

<pre>urlpatterns = patterns('',
    (r'^/todos/(?:(?P&lt;id&gt;\d+)/?)?(?:;(?P&lt;noun&gt;\w+))?/?$',
        TodoCollection()),
)</pre>

<p>Ok, maintenant voyons voir ce qui se cache dans TodoCollection&nbsp;:</p>

<pre>class TodoCollection(GenericCollection):
    def __call__(self, request, **kw):
        return super(TodoCollection, self).__call__(request, 'todo', 'todo', **kw)</pre>

<p>TodoCollection hérite de GenericCollection qui est la classe de base permettant d'automatiser l'accès aux ressources. Seule la fonction __call__ doit être réécrite pour tenir compte du nom de l'application et du modèle (vous pouvez encore plus automatiser en passant ces argument dans l'URL ou dans un dictionnaire mais nous verrons par la suite que cette nouvelle classe peut être utile pour y placer les fonction spécifiques à nos ressources).</p>

<p>Arrivé dans GenericCollection, la requête va être redirigée vers la fonction appropriée selon les équivalences suivantes (notez le caractère facultatif des paramètres <em>id</em> et <em>noun</em> dans l'expression régulière)&nbsp;:</p>

<ul>
<li>si c'est un GET sans id, redirection vers la fonction <strong>list</strong>&nbsp;;</li>
<li>si c'est un POST, redirection vers la fonction <strong>create</strong>&nbsp;;</li>
<li>si c'est un GET avec id, redirection vers la fonction <strong>retrieve</strong>&nbsp;;</li>
<li>si c'est un PUT avec id, redirection vers la fonction <strong>update</strong>&nbsp;;</li>
<li>si c'est un DELETE avec id, redirection vers la fonction <strong>delete</strong>&nbsp;;</li>
</ul>

<p>Dans le cas où il y a argument <strong>noun</strong>, la redirection s'effectue vers la fonction <strong>verbeHTTP_noun</strong> ce qui permet d'ajouter des vues si vous avez des besoins spécifiques, typiquement pour afficher un formulaire de mise à jour d'une ressource vous devrez pointer vers une URI de ce type&nbsp;:</p>

<p>/todos/{id};update_form</p>

<p>qui redirigera vers la fonction <strong>get_update_form</strong> de votre classe Collection.</p>

<p>Vous avez compris le principe&nbsp;? Étudions maintenant une fonctionnalité en particulier (attention la suite est un peu brutale, pour un vrai exemple je vous recommande celui du paquet).</p>

<h2>Trêve de confirmation</h2>

<p>Un <a href="http://www.alistapart.com/articles/neveruseawarning">récent article sur A List Apart</a> évoquait les avantages d'une annulation possible d'une action par rapport à une confirmation préalable. Il est vrai que les messages de confirmation sont toujours frustrants et sont de toute manière tellement banalisés aujourd'hui qu'ils ne sont plus lus par l'utilisateur.</p>

<p>Suite à cet article, une <a href="http://simonwillison.net/2007/Jul/17/undo/">discussion intéressante sur son implémentation dans Django</a> chez Simon Willison a aboutit à <a href="http://nathanostgard.com/archives/2007/7/18/undelete-in-django/">son implémentation</a> chez Nathan Ostgard m'ont permis d'intégrer cette fonctionnalité à moindre coût.</p>

<p>Elle impose tout de même d'ajouter un champ, deux fonctions et un manager à votre modèle&nbsp;:</p>

<pre>class TrashManager(models.Manager):
    def get_query_set(self):
        return super(TrashManager, self) \
            .get_query_set().filter(trashed_at__isnull=True)

    def get_trashed(self):
        return super(TrashManager, self) \
            .get_query_set().filter(trashed_at__isnull=False)


class Todo(models.Model):
    [...]
    trashed_at = models.DateTimeField(blank=True, null=True, editable=False)
    objects = TrashManager()

    def trash(self):
        self.trashed_at = datetime.now()
        self.save()

    def restore(self):
        self.trashed_at = None
        self.save()</pre>

<p>Cela vous permet de placer les ressources «&nbsp;supprimées » dans une corbeille temporaire permettant leur récupération après suppression malencontreuse (l'effet Ooops!). La base doit ensuite être régulièrement purgée ce qui est simplifié par l'accès aux éléments de la corbeille avec le manager&nbsp;:</p>

<pre>model.objects.get_trashed()</pre>

<p>Voyons maintenant ce que ça donne avec ma solution. Ce cas est très particulier et c'est intéressant car on va accéder aux limites de la solution justement. En effet, la suppression doit normalement être effectuée via un DELETE mais dans notre cas une mise dans la corbeille signifie une modification de la ressource et donc un PUT. Cruel dilemme&nbsp;!</p>

<p>Nous allons devoir créer une nouvelle méthode à notre classe gérant ce cas particulier, celle-ci sera accessible via&nbsp;:</p>

<pre>/todos/{id};trash</pre>

<p>qui redirigera vers la fonction (simplifiée pour l'exemple)&nbsp;:</p>

<pre>    def put_trash(self):
        self.item_instance.trash()
        message = _("Item trashed successfully. \
            &lt;a href=\"%s;recover?_method=put\" title=\"\"&gt;Restore?&lt;/a&gt; \
            " % self.id)
        self.request.user.message_set.create(message=message)</pre>

<p>Cette fonction est bien accessible via un PUT ce qui reste correct (si un client à ce service web est implémenté, il utilisera directement DELETE sans avoir besoin de confirmation). Un lien est ensuite proposé à l'utilisateur pour annuler cette «&nbsp;suppression » qui lui est beaucoup moins RESTful...</p>

<p>En effet, pour simplifier la récupération j'ai préféré placer un lien (ce qui n'est pas forcément conforme aux règles d'ergonomie qui stipulent qu'une donnée ne doit être modifiée qu'à travers un formulaire, d'où l'aspect si <del>hideux</del> reconnaissable des boutons de formulaires). Du coup je suis obligé de passer la méthode en argument pour faire un faux PUT, histoire d'être tout de même cohérent au niveau de ma classe&nbsp;:</p>

<pre>    def put_recover(self):
        self.model.objects.get_trashed().get(pk=self.id).restore()
        message = _("Item recovered successfully.")
        self.request.user.message_set.create(message=message)
        return HttpResponseRedirect('.')</pre>

<p>Ouf, on y est tout de même arrivé (il faut modifier le middleware du début pour qu'il utilise request.REQUEST et non request.POST si vous souhaitez faire du faux PUT avec du GET).</p>

<h2>Conclusion et évolutions</h2>

<p><strong>La solution permettant de gérer des collections génériques est satisfaisante (même s'il manque encore quelques fonctionnalités) et constitue un bon exemple de ce qui peut être fait à la fois avec Django et avec REST et c'est plus dans cette optique que je la publie.</strong></p>

<p>Il est parfois difficile de s'en tenir à une architecture RESTful dans les cas extrêmes et certains impératifs peuvent nécessiter quelques entorses aux règles que vous vous êtes fixé. Le plus important est d'en être conscient et d'assumer ses choix en connaissance de cause. Dans mon exemple sur l'annulation je sais très bien que c'est une fonctionnalité qui ne sera pas utilisée par un programme tiers.</p>

<p>Enfin deux mots sur ce qu'il resterait à implémenter (je reste dans le conditionnel car je pense que le GSoC permettra prochainement de faire la même chose en mieux, du moins je l'espère et je participe en ce sens)&nbsp;:</p>

<ul>
<li>Gérer différents formats de représentation des ressources (json, xml, etc).</li>
<li>Gérer les différentes erreurs possibles avec les codes appropriés (403, etc).</li>
<li>Rendre possible l'utilisation d'une classe avec url_reverse, notamment pour utiliser le tag {% url %} dans les templates.</li>
</ul>

<p>En attendant, vous pouvez toujours <a href="#">télécharger la version actuelle</a> et jouer avec&nbsp;! (n'oubliez pas d'ajouter le dossier à votre $PYTHONPATH...)</p>
      </div>
    </article>
    <footer>
      <h6 property="schema:datePublished">— 07/08/2007</h6>
    </footer>
  </section>
  <section>
    <div>
      <h3>Articles peut-être en rapport</h3>
      <ul>
        <li><a href="/david/biologeek/archives/20080604-architecture-web-moderne-et-agile/" title="Accès à ★ Architecture web moderne et agile">★ Architecture web moderne et agile</a></li>
        <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/20091211-pourquoi-python-et-django/" title="Accès à ★ Pourquoi Python et Django">★ Pourquoi Python et Django</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">vdemeester</span> le <span class="comment-date" property="schema:commentTime">08/08/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Salut,<br />
<br />
encore un article super intéressant, au moment où je me posais le même genre de question/problème pour mon application django en cours. (ça fait longtemps que j'ai pas commenté dis donc :D)<br />
<br />
&quot;* Gérer différents formats de représentation des ressources (json, xml, etc).&quot;<br />
<br />
Justement, imaginons que je veuille supporter les différents formats, quelles seraient les solutions pour faire comprendre à nos méthode que c'est tel ou tel format qui est passé ?<br />
<br />
Sinon, et atompub alors, on en parle pas ? :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">08/08/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Salut Vincent,<br />
<br />
Pour les formats, soit dans les headers (mais les crawlers ne vont avoir qu'une seule représentation), soit dans l'url : avant (/json/lasuite) ou après (/lasuite.json) je sais pas encore ce qui est le plus pratique.<br />
<br />
Pour atompub, ça arrive à grand pas : <a href="http://code.google.com/p/django-atompub/" title="http://code.google.com/p/django-atompub/" rel="nofollow">code.google.com/p/django-...</a><br />
<br />
J'en parlerais probablement à ce moment là.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Brice Carpentier</span> le <span class="comment-date" property="schema:commentTime">21/08/2007</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>À noter que le middleware NE FONCTIONNE PAS avec mod_python (request.method y est une propriété uniquement accessible en écriture). Je viens de m'en apercevoir et suis actuellement à la recherche d'un contournement de ce problème.</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>