OUJOOD.COM
Une fois que vos données sont prêtes à être traduites par un sérialiseur, il faut un chef d'orchestre pour réceptionner les appels des clients (navigateurs, mobiles) et renvoyer la réponse. Dans Django classique, on utilise des vues. Avec DRF, on utilise des API Views. Elles font le même travail, mais avec des super-pouvoirs dédiés au format JSON.
Le décorateur @api_view
Si vous aimez travailler avec des fonctions, c'est l'outil le plus simple. Ce décorateur transforme une fonction Python ordinaire en une vue capable de comprendre les requêtes API. Il gère automatiquement les erreurs si un client utilise une mauvaise méthode HTTP (comme envoyer un POST sur une vue qui n'accepte que le GET).
from rest_framework.decorators import api_view
from rest_framework.response import Response
@api_view(['GET'])
def liste_articles(request):
# Logique de récupération des données
return Response({"message": "Voici vos articles"})
La classe APIView
Pour des projets plus structurés, je recommande d'utiliser la classe APIView. Elle permet de séparer proprement la logique selon la méthode utilisée. Au lieu d'avoir une suite de "if" dans une fonction, vous créez des méthodes get(), post(), put() ou delete() au sein de la même classe.
from rest_framework.views import APIView
from rest_framework.response import Response
class ArticleDetail(APIView):
def get(self, request, id):
# Logique pour lire un article
return Response({"id": id})
Les vues génériques : la puissance de DRF
Pourquoi réécrire sans cesse le code pour lister, créer ou supprimer des objets ? DRF propose des Generic Views qui contiennent déjà toute la logique. Il vous suffit de leur donner un modèle et un sérialiseur, et Django s'occupe du reste. C'est un gain de temps phénoménal qui évite bien des bugs répétitifs.
Une fois vos vues créées, il ne reste plus qu'à les rendre accessibles via des adresses web précises. C'est ce que nous allons voir dans la leçon sur les URLs d'API Django REST Framework.
Par carabde | Mis à jour le 08/05/2026