Aller au contenu principal

Les briques de base de Django DRF

Repères utiles :

info

Cette note explique les composants essentiels que l'on retrouve dans un projet Django DRF : modèles, serializers, vues, viewsets, routers, authentification et permissions. Le but est de comprendre leur rôle sans se noyer trop tôt dans le code.

1. Pourquoi cette note est importante​

Quand on découvre Django DRF, on entend très vite une série de mots qui peuvent sembler abstraits :

  • modèle
  • serializer
  • vue
  • viewset
  • router
  • auth
  • permissions

Le problème, c'est qu'on peut les mémoriser sans vraiment comprendre comment ils coopèrent.

Or, pour progresser, il faut une image mentale simple.

2. La vision d'ensemble en une phrase​

Dans un backend Django DRF :

  • le modèle représente la donnée métier
  • le serializer transforme et valide la donnée échangée
  • la vue ou le viewset porte la logique d'accès
  • le router branche les routes
  • l'authentification identifie l'utilisateur
  • les permissions décident ce qu'il a le droit de faire

3. Première brique : le modèle​

Le modèle représente une entité importante de ton domaine.

Exemples :

  • User
  • Project
  • Task
  • Order
  • Invoice
  • Inspection

Un modèle sert à définir :

  • les champs importants
  • les relations entre entités
  • une partie des contraintes du domaine

En pratique, le modèle est très lié à la base de données. Mais il ne faut pas le voir uniquement comme une table. Il faut aussi le voir comme une représentation structurée d'un objet métier.

Intuition simple​

Si ton application gère des projets, le modèle Project répond à la question :

qu'est-ce qu'un projet dans ce système ?

4. Deuxième brique : le serializer​

Le serializer est l'une des grandes briques spécifiques de DRF.

Il joue deux rôles majeurs.

Rôle 1 — Représenter la donnée​

Quand le backend veut renvoyer une ressource au client, il doit produire une forme exploitable, souvent du JSON. Le serializer aide à produire cette représentation.

Rôle 2 — Valider la donnée entrante​

Quand le client envoie des données, le serializer aide à vérifier :

  • que les champs attendus sont présents
  • que les types sont corrects
  • que certaines règles sont respectées

Intuition simple​

Le serializer répond à la question :

comment cette ressource est-elle montrée ou acceptée par l'API ?

5. Troisième brique : la vue​

La vue reçoit une requête et décide comment répondre.

Elle orchestre notamment :

  • la lecture de la requête
  • l'appel à la logique utile
  • le choix du serializer
  • la construction de la réponse

Intuition simple​

La vue répond à la question :

que doit faire le backend quand cette route est appelée ?

6. Quatrième brique : le viewset​

Le viewset est une façon pratique de regrouper plusieurs actions autour d'une même ressource.

Au lieu d'avoir une logique dispersée, on peut centraliser :

  • la liste
  • le détail
  • la création
  • la mise à jour
  • la suppression

Cela est particulièrement confortable quand une ressource suit une logique CRUD classique.

Intuition simple​

Le viewset répond à la question :

quelles sont les opérations API cohérentes autour de cette ressource ?

7. Cinquième brique : le router​

Le router sert à relier automatiquement certains viewsets à des routes API.

Il aide à éviter de réécrire manuellement trop de configuration répétitive.

Par exemple, il peut générer une structure cohérente pour :

  • la liste d'une ressource
  • son détail
  • d'autres actions associées

Intuition simple​

Le router répond à la question :

comment les points d'entrée API sont-ils branchés proprement ?

8. Sixième brique : l'authentification​

L'authentification sert à répondre à une question fondamentale :

qui appelle l'API ?

C'est le mécanisme qui permet d'identifier l'utilisateur ou le client.

Important : l'authentification ne dit pas encore ce que cet utilisateur a le droit de faire. Elle dit d'abord qui il est.

9. Septième brique : les permissions​

Les permissions répondent à l'autre grande question :

maintenant qu'on sait qui appelle, que cette personne a-t-elle le droit de faire ?

Exemples :

  • lecture autorisée, écriture interdite
  • accès réservé aux utilisateurs connectés
  • accès réservé à certains rôles
  • accès limité aux objets appartenant à l'utilisateur

Intuition simple​

L'authentification identifie. Les permissions autorisent ou refusent.

10. Le cycle mental complet d'une requête​

Voici une manière simple d'imaginer le passage d'une requête dans Django DRF.

Étape 1 — Le client appelle une route​

Exemple mental : le frontend veut consulter ou créer une ressource.

Étape 2 — La route trouve la bonne logique​

Le système détermine quelle vue ou quel viewset doit traiter cette requête.

Étape 3 — L'authentification identifie l'appelant​

Le backend essaie de savoir qui fait la demande.

Étape 4 — Les permissions vérifient les droits​

On détermine si cette personne a le droit d'effectuer l'action demandée.

Étape 5 — Le viewset ou la vue exécute la logique​

Le backend décide quoi faire : lire, créer, modifier, supprimer, déclencher une action métier, etc.

Étape 6 — Le serializer valide ou représente la donnée​

  • en entrée : validation
  • en sortie : transformation vers une réponse exploitable

Étape 7 — Le modèle et l'ORM interagissent avec la base​

Les données sont lues ou enregistrées.

Étape 8 — La réponse est renvoyée au client​

Le client reçoit une réponse structurée.

11. Exemple conceptuel très simple​

Imaginons une ressource Project.

Le modèle​

Il décrit ce qu'est un projet :

  • nom
  • description
  • propriétaire
  • statut
  • date de création

Le serializer​

Il décide :

  • quels champs l'API montre
  • quels champs doivent être validés à la création ou mise à jour

Le viewset​

Il gère les actions :

  • lister les projets
  • afficher un projet
  • créer un projet
  • modifier un projet
  • supprimer un projet

Le router​

Il branche ces actions aux routes correspondantes.

L'authentification​

Elle vérifie qui appelle.

Les permissions​

Elles décident par exemple qu'un utilisateur ne peut modifier que ses propres projets.

12. Ce qu'il ne faut pas confondre​

Modèle vs serializer​

Le modèle décrit la structure métier et la persistance. Le serializer décrit la représentation et la validation API.

Vue / viewset vs router​

La vue ou le viewset contient la logique de traitement. Le router branche cette logique aux routes.

Authentification vs permissions​

L'authentification répond à “qui ?”. Les permissions répondent à “a-t-il le droit ?”.

13. Où se trompent souvent les débutants​

Erreur 1 — Tout mettre dans le serializer​

Le serializer ne doit pas devenir un endroit où l'on met toute la logique métier du monde.

Erreur 2 — Tout mettre dans la vue​

La vue ne doit pas être un bloc géant confus qui mélange validation, règles métier, permissions, accès aux données et transformations.

Erreur 3 — Penser que le router “fait la logique”​

Le router n'exécute pas la logique métier. Il connecte les routes.

Erreur 4 — Penser qu'un modèle suffit à définir l'API​

Ce n'est pas parce qu'un objet existe en base qu'il doit être exposé tel quel dans l'API.

Erreur 5 — Sous-estimer les permissions​

Une API peut sembler fonctionner techniquement tout en étant dangereuse du point de vue des accès.

14. Comment retenir simplement les rôles​

Tu peux retenir la formule suivante :

  • modèle = ce que le système stocke
  • serializer = ce que l'API accepte ou montre
  • vue / viewset = ce que l'API fait
  • router = comment on y accède
  • auth = qui appelle
  • permissions = ce qu'il a le droit de faire

15. Pourquoi cette séparation est utile​

Cette séparation est précieuse parce qu'elle évite de mélanger toutes les responsabilités.

Si tout est mélangé :

  • le projet devient vite opaque
  • les erreurs sont plus dures à corriger
  • les permissions deviennent fragiles
  • l'évolution du produit devient pénible

Au contraire, quand les briques ont des rôles relativement clairs, le projet devient plus lisible.

16. Brique technique ne veut pas dire pensée technique seulement​

Un point important : ces briques ne sont pas seulement techniques. Elles traduisent aussi une manière de penser le backend.

Par exemple :

  • si tu ne sais pas quel acteur a le droit de modifier un objet, tu auras du mal à écrire les permissions
  • si tu ne sais pas quelles données doivent être exposées, tu auras du mal à écrire le serializer
  • si tu ne sais pas quelles opérations produit comptent vraiment, tu auras du mal à dessiner le viewset

C'est pour cela que Comment penser une API avec Django DRF doit toujours rester proche de cette note.

17. Résumé final​

Les briques de base de Django DRF forment une chaîne cohérente :

  • le modèle structure la donnée métier
  • le serializer la valide et la représente
  • la vue ou le viewset gère le traitement
  • le router branche les routes
  • l'authentification identifie l'appelant
  • les permissions contrôlent les droits

Comprendre cette chaîne est essentiel avant de plonger dans des tutoriels plus orientés cas d'usage.

18. Pour aller plus loin​

Lire ensuite :