Aller au contenu principal

Comprendre Django REST Framework

Repères utiles :

info

Cette note explique ce qu'est Django REST Framework, ce qu'il ajoute à Django, pourquoi il est si souvent utilisé pour les APIs, et dans quels cas il peut être inutile ou excessif.

1. Le point de départ​

Une fois que l'on comprend Comprendre Django, une nouvelle question apparaît naturellement :

Django est déjà capable de gérer des requêtes, des vues, des utilisateurs et des données. Alors pourquoi ajouter Django REST Framework ?

C'est une excellente question.

La réponse courte est la suivante :

DRF est une couche qui rend la construction d'APIs beaucoup plus pratique, cohérente et maintenable sur Django.

2. Définition simple​

Django REST Framework, souvent abrégé DRF, est une extension de Django pensée pour construire des APIs web de manière plus propre et plus confortable.

Avec DRF, on peut plus facilement :

  • exposer des données en JSON
  • valider des entrées
  • sérialiser des objets
  • gérer l'authentification API
  • gérer les permissions API
  • construire des endpoints CRUD propres
  • paginer, filtrer et rechercher

3. L'idée clé à retenir​

Django et DRF ne sont pas deux mondes concurrents.

La relation correcte est plutôt :

  • Django = le socle backend général
  • DRF = l'outillage spécialisé pour construire une API sur ce socle

Donc DRF n'existe pas “à la place” de Django. Il existe au-dessus de Django.

4. Le problème que DRF résout​

Sans DRF, il est tout à fait possible de construire une API avec Django seul. Mais très vite, tu dois gérer toi-même beaucoup d'éléments de manière plus artisanale :

  • transformer des objets Python en JSON
  • valider les données entrantes
  • standardiser les réponses
  • gérer des patterns CRUD répétitifs
  • mettre en place proprement auth et permissions API
  • rester cohérent d'un endpoint à l'autre

DRF résout cela en apportant des briques dédiées.

5. En langage simple : à quoi sert DRF ?​

Imagine que Django te donne la maison. DRF te donne l'équipement spécialisé pour transformer cette maison en backend API habitable et bien organisé.

Autrement dit, DRF aide à faire le passage de :

  • “un backend Django capable de répondre à des requêtes” vers
  • “une API claire, structurée, cohérente et exploitable par un frontend ou d'autres clients.”

6. Ce que DRF apporte concrètement​

6.1 Les serializers​

Les serializers sont l'une des briques centrales de DRF.

Ils servent à deux choses majeures :

  • transformer des objets complexes en données échangeables, souvent du JSON
  • valider les données reçues avant de les convertir en objets exploitables

C'est important, car une API échange constamment des données. DRF te donne donc un endroit propre pour exprimer les règles de validation et de transformation.

6.2 Des vues API plus adaptées​

Django possède déjà des vues. Mais DRF apporte des vues pensées pour les besoins API.

Elles aident à gérer plus naturellement :

  • lecture de ressources
  • création
  • mise à jour
  • suppression
  • format de réponse cohérent
  • statut HTTP approprié

6.3 Les ViewSets​

Les ViewSets permettent de regrouper dans une même logique les opérations classiques sur une ressource.

Par exemple, pour une ressource Project, on veut souvent :

  • lister
  • voir le détail
  • créer
  • modifier
  • supprimer

DRF propose un cadre naturel pour cela.

6.4 Les routers​

Les routers t'aident à générer proprement les routes API à partir de tes ViewSets. Cela réduit le bruit répétitif et améliore la cohérence globale.

6.5 Authentification et permissions adaptées aux APIs​

DRF facilite la gestion de questions comme :

  • qui appelle l'API ?
  • avec quel mécanisme d'authentification ?
  • que peut faire cet utilisateur ?
  • sur quelles ressources ?

6.6 Pagination, filtres, recherche​

Dans beaucoup d'APIs réelles, on ne veut pas seulement “renvoyer des données”. On veut aussi :

  • paginer des listes
  • filtrer selon des critères
  • trier
  • rechercher

DRF rend ces usages beaucoup plus naturels.

7. Pourquoi DRF est si populaire​

DRF est populaire parce qu'il combine plusieurs qualités importantes :

  • il repose sur Django, donc sur un socle mature
  • il résout des problèmes concrets de construction d'API
  • il reste très proche du modèle mental Django
  • il évite beaucoup de bricolage répétitif
  • il aide à faire des APIs lisibles et structurées

En pratique, DRF plaît beaucoup aux équipes qui veulent avancer vite sans sacrifier la structure.

8. Quand DRF est particulièrement pertinent​

DRF devient très pertinent quand tu veux construire :

  • un backend pour une app web moderne
  • un backend pour une app mobile
  • une API métier
  • une API avec utilisateurs et permissions
  • une API CRUD non triviale
  • un backend exposant des données métier à plusieurs clients
  • un produit qui a besoin d'une API maintenable

9. Quand DRF n'est pas forcément nécessaire​

Il faut aussi savoir dire non à DRF dans certains cas.

DRF peut être inutile ou excessif si :

  • tu n'as pas réellement besoin d'une API structurée
  • tu rends surtout des pages HTML côté serveur
  • ton besoin API est extrêmement petit et ponctuel
  • tu veux volontairement rester minimaliste sur un microservice très simple

La question n'est donc pas :

“DRF est-il bien ?”

La vraie question est :

“Est-ce que mon projet a vraiment besoin d'une couche API plus structurée que Django seul ?”

10. Ce que DRF ne fait pas à ta place​

DRF aide beaucoup, mais il ne remplace pas la réflexion produit et métier.

Il ne décide pas à ta place :

  • quelles ressources exposer
  • quelles règles métier appliquer
  • quelle stratégie de permissions choisir
  • quelle structure de projet est la plus saine
  • quels champs doivent être publics ou privés

Donc DRF est un très bon outil, mais pas un substitut à une bonne architecture.

11. Les erreurs de compréhension les plus fréquentes​

Erreur 1 — Croire que DRF est obligatoire dès qu'on utilise Django​

Ce n'est pas vrai. Django seul peut suffire pour certains projets.

Erreur 2 — Croire que DRF remplace Django​

C'est faux. DRF complète Django. Il ne le remplace pas.

Erreur 3 — Croire que faire une API revient à exposer toute la base telle quelle​

Très mauvaise idée. Une API n'est pas juste une “fenêtre brute” sur la base de données. Elle doit refléter un vrai besoin produit et respecter des règles métier.

Erreur 4 — Croire que serializer = simple convertisseur JSON​

Un serializer fait plus que cela. Il structure, transforme et valide les données.

Erreur 5 — Croire que permissions = détail secondaire​

Dans un vrai backend, les permissions sont centrales. Beaucoup de problèmes sérieux viennent d'une gestion naïve des accès.

12. DRF et la notion de ressource​

Une bonne manière de comprendre DRF est de penser en termes de ressources.

Une ressource peut être :

  • un utilisateur
  • un projet
  • une commande
  • un dossier
  • une analyse
  • un ticket

Pour chaque ressource, on se demande :

  • qui peut la voir ?
  • qui peut la créer ?
  • qui peut la modifier ?
  • qui peut la supprimer ?
  • comment la représenter dans l'API ?

DRF est très confortable pour organiser cela.

13. Ce que DRF apporte en termes de confort mental​

Au-delà de la technique, DRF apporte surtout un confort de pensée.

Il pousse à structurer l'API autour de questions claires :

  • quelle est la ressource ?
  • quelle est la représentation des données ?
  • quelle logique de traitement ?
  • quelle politique d'accès ?
  • quelle route ?

Ce cadre réduit beaucoup le désordre dans les APIs qui grandissent.

14. Relation entre Django, DRF et le frontend​

Quand on construit une application moderne avec frontend séparé, le frontend ne discute pas directement avec la base. Il discute avec une API.

Dans ce schéma :

  • le frontend affiche et orchestre l'expérience utilisateur
  • Django + DRF gère les données, la sécurité et la logique métier
  • la base stocke l'état durable

C'est pour cela que DRF revient si souvent dans les architectures web et mobile.

15. Faut-il toujours commencer un projet Django avec DRF ?​

Pas nécessairement.

Mais si tu sais déjà que le projet devra fournir une API propre à :

  • un frontend JS
  • une app mobile
  • des clients externes
  • un autre système

alors DRF devient très vite un choix logique.

16. L'intuition à retenir​

Si tu devais retenir une seule phrase, ce serait celle-ci :

Django te donne le backend général. DRF te donne une manière propre et robuste de le transformer en API.

17. Pont vers la suite​

Après cette note, la suite logique n'est pas encore le code. La suite logique est de comprendre comment penser une API.

Car le vrai risque n'est pas de manquer d'outils. Le vrai risque, c'est de construire une API confuse, mal découpée ou trop couplée à l'interface.

La prochaine note à lire est donc : Comment penser une API avec Django DRF

18. Résumé final​

Django REST Framework est une extension de Django conçue pour simplifier et structurer la création d'APIs.

Il apporte notamment :

  • serializers
  • vues API adaptées
  • viewsets
  • routers
  • auth et permissions API
  • pagination, filtres et recherche

Il est particulièrement pertinent quand on veut construire une API sérieuse, cohérente et maintenable.

Mais il ne faut ni le considérer comme obligatoire dans tous les projets, ni croire qu'il remplace la réflexion architecturale.

L'idée centrale est simple :

DRF n'est pas seulement un outil pour “sortir du JSON”. C'est un cadre pour construire une API propre sur Django.

19. Pour aller plus loin​

Lire ensuite :