article.md 4.6KB
title: ★ Django-ROA, pour une architecture orientée ressources slug: django-roa-pour-une-architecture-orientee-ressources date: 2009-05-26 00:00:58 type: post vignette: images/logos/django_pony.png contextual_title1: Rencontres Django à Marseille le WE du 24/25 avril contextual_url1: 20100121-rencontres-django-marseille-le-we-du-2425-avril contextual_title2: ★ Pourquoi Python et Django contextual_url2: 20091211-pourquoi-python-et-django contextual_title3: ★ Astuces et bonnes pratiques Django contextual_url3: 20080211-astuces-et-bonnes-pratiques-django
Il y a un projet sur lequel je travaille depuis un moment maintenant dans le cadre de mes prestations et que j’ai décidé de libérer (sous licence BSD) car je pense qu’il peut être utile à pas mal de monde : Django-ROA.
Qu’est-ce que ça fait ?
Il s’agit de pouvoir gérer ses ressources distantes normalement accessibles en REST directement via l’ORM et les modèles de Django. Le module va s’occuper (comme le montre le merveilleux schéma ci-dessous) de convertir la requête Django initiale en une requête HTTP et de convertir/déserializer la réponse en un objet Django :
Ok pour le fonctionnement mais qu’en est-il des applications ?
Le module a originellement été développé pour s’intégrer dans les architectures orientées services (SOA) ayant une contrainte REST (d’où le ROA). Cela signifie que vous pouvez brancher votre application sur une base de données métier sous réserve qu’elle ait une interface HTTP. Ce qui ouvre la porte aux bases non supportées par Django nativement, aux entrepôts de données et aux multi-databases puisque vous pouvez spécifier une URI par modèle… Soyons encore plus fous, CouchDB parle le HTTP, et bien il suffirait d’un connecteur approprié pour pouvoir accéder aux documents via des modèles Django !
Lors d’EuroDjangoCon, Jesper venait de sortir django-piston (qui est utilisé pour les tests de django-roa) et faisait des tests d’application sur Pinax. J’ai pu vérifier en communiquant avec l’API mise en place sur sa machine que je pouvais éditer des objets Pinax via une interface d’administration de Django qui était lancée sur ma machine. Ce qui signifie que l’on pourrait imaginer une interface d’administration commune à plusieurs projets (pas forcément Django) présentant des API.
Si vous avez d’autres idées d’applications, n’hésitez pas à laisser libre cours à votre imagination. Je n’ai pas parlé de RDF mais vous pensez bien que ce module est une partie intégrante de ce que j’ai appelé architecture moderne et agile ;-).
Comment l’utiliser ?
Je ne vais pas reproduire la doc ici mais c’est relativement simple, il suffit d’hériter du Model de django-roa et de définir l’URL de la ressource avec la méthode get_resource_url_list.
Après, il y a beaucoup de settings et méthodes pour configurer tout ça, le plus intéressant pour découvrir le module est probablement ROA_MODELS qui permet de passer facilement d’une architecture locale (pour développer) à une architecture orientée ressources (pour tester grandeur nature). Sinon la lecture des tests peut être d’une grande aide.
Notez qu’il est nécessaire de patcher Django (du moins pour l’instant) avec le patch lié au ticket #10109 pour pouvoir utiliser le module avec les relations ManyToMany.
Comment participer ?
En testant le module dans un premier temps, en enrichissant la documentation au besoin (je peux facilement vous laisser des droits si vous avez un compte BitBucket), en proposant des patchs ou tout simplement en discutant des concepts.
J’aurais le plaisir d’en présenter brièvement les détails lors de Pycon-fr (dimanche après-midi) où j’espère vous retrouver nombreux. Il y aura aussi un atelier Django le samedi après-midi pour ceux et celles qui voudraient s’y mettre !