Utiliser une architecture RESTful avec Django

Qu'est-ce que REST ?

Une architecture dite RESTful permet d’identifier des ressources (correspondant classiquement à des modèles ou classes d’objets stockés en base de données) accessibles par l’utilisateur, qu'il soit un être humain ou un système informatique, via des URLs et de modifier leur état via des verbes et paramètres de la requête HTTP invoquant cette URL.

Chaque URL est reliée à une fonction (qu’on appelle une "vue" dans Django) capable d’effectuer un traitement sur une requête HTTP, puis de renvoyer une réponse HTTP en fonction du verbe et des paramètres HTTP qu’elle a reçus dans la requête initiale.

Chaque application Django contient les vues, modèles et URLs propres à son fonctionnement. Notons qu’il sera pratique de nommer les URLs, de sorte que si un jour nous décidons de changer l’adressage de l’application, nous n’aurons pas à modifier les templates de page, ceux-ci ne contenant que les noms des URLs et non les URLs elles-mêmes.

Pour chaque ressource, on compte classiquement 8 types de vues, mais il est bien sûr possible d’en implémenter des supplémentaires si besoin, ou de ne pas implémenter celles qui ne sont pas requises. En voici la liste, accompagnée d'une description :

Différence entre modèles et ressources

Il est important de noter la différence entre modèle et ressource. Dans le cas d'un système de banque en ligne par exemple, nous pouvons décider qu’il sera impossible à un utilisateur de créer un compte depuis le site Web de la banque. Par conséquent, aucune URL ni vue ne correspondra à ce cas d’utilisation, puisqu’il n’est pas prévu.

En revanche, dans le modèle Django correspondant aux comptes bancaires stockés en base de données, une fonction permettant de créer un objet Compte rattaché à cet utilisateur devra pouvoir être invoquée lors de la création d’un nouvel accès pour un client et du référencement sur le site de tous ses comptes en banque existants. Nous voyons bien ici qu’exclure des vues en REST ne signifie pas que la fonctionnalité n’est pas présente à l’intérieur du système, simplement qu’elle n’est pas rendue disponible à l’utilisateur.

Les verbes HTTP PUT et DELETE

Un choix important à faire lors de l'implémentation d'une architecture REST est l'utilisation des verbes PUT et DELETE comme cela a été prévu dans la philosophie de REST. En effet, pour respecter cette philosophie, un verbe HTTP (GET, POST, PUT, DELETE) devrait correspondre à un unique type d'action du quatuor CRUD (Create, Read, Update, Delete) en base de données.

Cependant, utiliser ces deux verbes sur le Web peut s'avérer difficile car :

• La plupart des navigateurs ne savent pas interpréter ces valeurs lorsqu'elles sont spécifiées dans les attributs "method" des formulaires ;
  
• Certains proxys n'autorisent que les méthodes GET et POST.

Il existe des solutions au premier problème, les plus courantes étant soit d'insérer un champ caché dans un formulaire HTML POST qui spécifie quelle méthode utiliser, soit d'utiliser un script JavaScript pour envoyer une requête HTTP de manière asynchrone. Le second problème en revanche dépendra des contraintes des utilisateurs de l'application.

Pour un maximum de compatibilité, nous recommandons d'utiliser la première solution en n'implémentant que GET et POST pour des sites Web classiques (HTML retourné à des internautes), et deux méthodes (POST et PUT ou POST et DELETE) si vous développez une API (XML, JSON ou autre format de données retourné à d'autres systèmes informatiques). De cette manière, votre site fonctionnera partout et vous laisserez le choix aux développeurs utilisant votre API de respecter la philosophie de REST ou d'être plus pragmatiques.

Pour aller plus loin