Mettez en place une API avec Django REST Framework

Appliquez un filtre sur les données retournées

Sur notre boutique, nous avons la possibilité de désactiver des catégories, produits et articles afin de ne pas les présenter à nos utilisateurs. Cela permet de gérer les articles qui ne sont plus disponibles, par exemple, ou de réduire le nombre de catégories proposées si celles-ci ne contiennent ni produit, ni article activé.

Notre API ne permet pas encore cette possibilité. Pour cela, nous allons simplement modifier le queryset retourné par notre méthode  get_queryset  en ajoutant un filtre :

class CategoryViewset(ReadOnlyModelViewSet):
 
    serializer_class = CategorySerializer
 
    def get_queryset(self):
        return Category.objects.filter(active=True)

Redéfinir le queryset d’un ModelViewset  permet de définir quelles sont les entités consultables lorsque la liste ou le détail d’une entité sont demandés. Consulter, modifier ou supprimer une catégorie non active retourne à présent un status code 404. Tout cela est géré par DRF par le ModelViewset.

Utilisez un filtre transmis dans l’URL

Lorsque nos utilisateurs naviguent sur notre boutique, il se peut qu’ils souhaitent récupérer les produits d’une catégorie grâce à un appel fait à notre API. Sauf que pour le moment, notre endpoint de produits ne permet pas de filtrer par catégorie.

Pour réaliser cela, nous allons accepter un paramètre dans l’URL qui sera l’identifiant de la catégorie, pour ne renvoyer que les produits correspondants. Le paramètre sera nommécategory_id, ce qui donnera une URL sous le formathttp://127.0.0.1:8000/api/product/?category_id=1.

Éditons notre classe ProductViewset  pour qu’elle applique un nouveau filtre si le paramètre est présent. Profitons-en pour également appliquer le filtre sur les produits actifs :

class ProductViewset(ReadOnlyModelViewSet):
 
    serializer_class = ProductSerializer
 
    def get_queryset(self):
    # Nous récupérons tous les produits dans une variable nommée queryset
        queryset = Product.objects.filter(active=True)
        # Vérifions la présence du paramètre ‘category_id’ dans l’url et si oui alors appliquons notre filtre
        category_id = self.request.GET.get('category_id')
        if category_id is not None:
            queryset = queryset.filter(category_id=category_id)
        return queryset

À présent, nous pouvons constater que le filtre est bien appliqué si nous consultons la liste des produits de la catégorie 1 avec l’URL http://127.0.0.1:8000/api/product/?category_id=1.

Et si nous demandons une catégorie qui n'existe pas, alors une liste de produits vide est retournée sans faire planter notre application :http://127.0.0.1:8000/api/product/?category_id=7777777.

Dans le screencast ci-dessous, je vous invite à me suivre dans la création de notre premier filtre :

Ainsi, les paramètres d’URL peuvent servir à appliquer toutes sortes de filtres sur les données retournées. N’hésitez pas à jouer avec, en permettant par exemple de forcer l’affichage des produits inactifs.

À vous de jouer

À votre tour ! Pour parfaire notre boutique, nous souhaitons mettre en place un endpoint de récupération des articles sur l’URL http://127.0.0.1:8000/api/article/. Il ne doit retourner que les articles actifs, et permettre de filtrer les articles retournés sur une catégorie avec un paramètre product_id.
Cet endpoint doit retourner les informations suivantes :

• L’identifiant de l’article ;

• La date de création et de modification de l’article ;

• Le nom de l’article ;

• Le prix de l’article ;

• L’identifiant du produit auquel appartient l’article.

Pour réaliser cela, vous pouvez partir de la branche P1C5_exercice. Elle contient déjà ce que nous venons de faire ensemble.

Une solution est proposée sur la branche P1C5_solution.

En résumé

• Redéfinir la méthode get_queryset  permet de définir les entités à prendre en compte dans l'endpoint.

• Il est possible d’utiliser des paramètres d’URL pour apporter des précisions sur l’action à réaliser (comme filtrer sur un critère particulier).

C’est maintenant l’heure d’écrire les premiers tests pour notre API ! Rendez-vous au prochain chapitre.