Django Form et DRF Serializer : Deux outils si proches, si différents, une analyse comparative

• Le Django Form est un outil conçu pour valider les données d'entrée HTML.
• Le DRF Serializer est un outil qui valide et transforme les données d'API JSON.
• Ces deux outils partagent des similitudes frappantes dans leur flux de travail : is_valid(), la gestion des données validées et le traitement des erreurs.
• De même, ModelForm et ModelSerializer se ressemblent par leur génération automatique de champs basée sur le modèle et leur structure de sauvegarde.

Similitudes entre Django Form et DRF Serializer

Lorsque nous utilisons Django, nous sommes souvent accompagnés (et parfois mis à l'épreuve) par deux gardiens essentiels : Django Form et le DRF (Django REST Framework) Serializer. Nous avons résumé leurs similitudes.

Ces deux compagnons, bien que chacun opère sur une scène différente (pages web vs API), partagent une ressemblance étonnante dans leur rôle et leur structure fondamentaux : « valider en toute sécurité les données externes pour les intégrer en interne, et empaqueter joliment les données internes pour les exporter vers l'extérieur ».

1. Comparaison des rôles en un coup d'œil

Pour faire une analogie simple, ils sont comme les « agents de sécurité et d'accueil » à l'entrée d'un grand magasin.

• Django Form : Il opère principalement dans le monde des pages web HTML. Il vérifie si les données saisies par l'utilisateur dans une fenêtre de navigateur (Form Data) sont correctes et, en cas d'erreur, affiche un message convivial comme « Veuillez réessayer ».
• DRF Serializer : Il travaille principalement dans l'univers des API qui échangent du JSON. Il convertit les données JSON envoyées par les applications mobiles ou les front-ends (React, Vue, etc.) en objets Python et, inversement, il « emballe » joliment (sérialise) les données de la base de données en JSON.

2. Pourquoi tant de similitudes ? Trois ressemblances structurelles

Les développeurs qui ont créé DRF ont été tellement impressionnés par l'excellence de la structure de Django Form qu'ils l'ont presque entièrement utilisée comme référence pour concevoir Serializer. C'est pourquoi la structure du code et son utilisation se ressemblent comme des jumeaux non identiques.

① La méthode de définition des champs est identique

La manière de spécifier le format des données attendues est absolument identique.

• Django Form :

from django import forms

class UserForm(forms.Form):
    username = forms.CharField(max_length=100)
    email = forms.EmailField()
    age = forms.IntegerField()

• DRF Serializer :

    from rest_framework import serializers

    class UserSerializer(serializers.Serializer):
        username = serializers.CharField(max_length=100)
        email = serializers.EmailField()
        age = serializers.IntegerField()

À l'exception du remplacement de forms par serializers, la logique de déclaration des champs est absolument la même.

② La validation et la méthode d'accès aux données sont identiques

Le flux des méthodes pour vérifier la sécurité des données et accéder aux données validées est cohérent.

1. Validation : Les deux approches appellent if form.is_valid(): ou if serializer.is_valid(): après avoir inséré les données.
2. Accès aux données validées : Les données nettoyées et validées sont stockées dans un dictionnaire appelé form.cleaned_data pour le Form, et serializer.validated_data pour le Serializer. Seul le nom diffère légèrement, mais la fonctionnalité est la même.
3. Vérification des erreurs : En cas d'échec de la validation, des messages d'erreur sont fournis sous forme de dictionnaire via form.errors ou serializer.errors.

③ Intégration avec les modèles (ModelForm vs ModelSerializer)

Le cœur de Django réside dans son intégration avec la base de données (Modèle). Ces deux outils disposent de classes « astuces » qui génèrent automatiquement les champs basés sur un modèle.

• Django ModelForm :

    class MyModelForm(forms.ModelForm):
        class Meta:
            model = MyModel
            fields = ['title', 'content']

• DRF ModelSerializer :

    class MyModelSerializer(serializers.ModelSerializer):
        class Meta:
            model = MyModel
            fields = ['title', 'content']

La syntaxe, utilisant la classe interne Meta pour spécifier le modèle de base et les champs à utiliser, est étrangement identique. Grâce à cela, l'appel de la méthode save() entraîne la création (create) ou la modification (update) automatique des données dans la base de données, de manière similaire.

En conclusion

• Le Django Form est un ami qui agit comme interprète entre HTML et Python, assurant la validation des données, et
• Le DRF Serializer est un ami qui agit comme interprète entre JSON et Python, assurant également la validation des données.

Si vous avez déjà travaillé avec Django Form, vous pouvez considérer le DRF Serializer comme « un Form qui gère le JSON au lieu du HTML », ce qui est correct à plus de 90 %. Inversement, si vous avez d'abord abordé le Serializer, le Form vous sera également facile à comprendre.

Cependant, je pense que de nombreux ingénieurs backend, bien que ces deux outils soient très similaires, se sentent plus à l'aise avec le Serializer qu'avec le Form, qui en est pourtant à l'origine. C'est mon cas également.

Vous êtes-vous déjà demandé pourquoi cette sensation ? Dans le prochain article, nous discuterons des raisons pour lesquelles Django Form, bien que similaire au Serializer, peut générer un certain malaise à l'usage.

Si cet article vous a été utile, n'hésitez pas à aimer et à attendre avec impatience le prochain !