Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage,
je m'appelle Nicolas Brondin-Bernard et aujourd'hui on va parler des data transfer
object qu'on appelle aussi les DTO, mais juste avant un petit message du sponsor du jour.
Un réseau mondial de connaissance et l'engagement de vous accompagner à toutes les étapes de vos
projets, de la recherche à la conception en passant par la maintenance, Farnel, votre fournisseur
de produits électroniques et industriels. Pour en savoir plus, rendez-vous sur fr.farnel.com.
Alors on va commencer cet épisode en disant que si vous créez des API et que ces API sont
accessibles depuis Internet, le concept de DTO est vraiment indispensable pour sécuriser vos
données. Prenons un petit exemple, l'exemple classique d'une API reste dans laquelle vous
manipulez des données utilisateurs. On va prendre par exemple une entité de données,
une structure de données très simplifiée avec simplement une classe qu'on va appeler
User Entity et puis qui aura tout simplement quatre attributs. Le premier c'est un entier qui
est un ID, le deuxième une chaîne de caractère pour l'email, une chaîne de caractère pour le
username pour le nom du disateur et la dernière c'est une chaîne de caractère pour le mot de
passe. Cette entité vous allez sûrement la récupérer depuis une base de données avec un ORM,
effectuer quelques traitements s'il besoin et la retourner dans votre réponse HTTP. Alors on
peut penser que c'est sécurisé parce qu'on a bien fait attention à ne jamais demander le mot de
passe ou l'email dans la requête SQL. Donc ces deux champs d'offre entre entités vont toujours
être vides quand le client récupère les données de profil d'un utilisateur. Sauf qu'un jour,
quelqu'un de votre équipe modifie la requête SQL et rajoute ces données parce qu'il en a besoin
dans une autre partie de la logique de votre application. Et là en quelques heures, les
emails et les mots de passe se retrouvent dans la nature puisque ils sont retournés par le client
et vous allez forcément avoir un utilisateur ou une utilisatrice malveillante qui va réussir à
trouver que ces infos sont retournés par la pays et donc récupérer potentiellement toute votre base
d'email et de mots de passe même si les mots de passe sont achés etc. Quelle est l'une des solutions
mais en tout cas l'une des étapes obligatoires pour filtrer ces données ? C'est ce qu'on appelle
des DTO. Les DTO donc Data Transfer Objects, ce sont des objets qui représentent un sous-ensemble
de vos entités et qui ne contiennent uniquement que les informations qui sont transférées entre le
client et la pays pour éviter tout de suite de données. Par exemple, un DTO pour un objet user
qui sera retourné dans une liste publique par exemple, une liste d'utilisateurs, et bien notre
classe justement pour créer ces objets, c'est DTO, on aura par exemple une classe public user DTO et
qu'il n'aura cette fois que deux attributs. L'attribut d'entier pour l'ID et l'attribut de chaîne
de caractère pour le nom d'utilisateur. Comme ça, il n'y a aucun risque de renvoyer le mot de passe
par exemple par inadvertance. Même si la requête à la base de données est modifiée, on ne renverra
jamais ces infos là parce qu'avant chaque réponse du serveur, les entités qui naviguent dans le
serveur seront transformées en DTO et inversement, lorsque vous allez recevoir une requête en 30,
vous allez créer un DTO pour ne filtrer que les données dont vous avez besoin. Par exemple, si on
voulait créer un DTO spécifique pour recevoir les données lors de l'inscription d'un utilisateur,
on va créer un user create DTO par exemple, on peut l'appeler comme on veut, qui ne
contiendra que trois attributs, une chaîne de caractère pour l'email, une pour le nom d'utilisateur et
une pour le mot de passe. Cette fois-ci, on n'a pas d'entier pour l'ID puisque évidemment,
aucun utilisateur ne va nous envoyer un ID puisqu'il est en train de créer l'utilisateur et donc,
l'ID va se créer en base de données. À chaque fois que vous allez avoir une requête en 30 ou une
réponse sortante, les entités que vous utilisez dans votre base de données et dans la logique de
votre app, enfin de votre app côté serveur, elles vont être filtrées puisqu'on va automatiquement
passer du DTO à l'entité ou de l'entité au DTO en sortant. Alors en plus, il y a quand même
une utilisation bonus de ces objets-là, c'est qu'en plus de sécuriser les données de transfert,
eh bien les DTO, ils peuvent être utilisé pour documenter plus clairement les entrées sorties
de votre API en générant automatiquement la doc au plan API par exemple. Si vous avez un générateur,
bien vous allez pouvoir indiquer ces DTO-là au lieu de vos entités à la documentation et ça va
se faire tout seul et ça sera beaucoup plus lisible et surtout sécurisé. Alors évidemment,
quand on entend ça, on peut penser que les DTO, toutes ces classes qu'on va venir créer pour
justement créer ces objets sécurisés, eh bien ils vont un petit peu à l'encontre du principe dry,
donc don't repeat yourself, puisqu'on va avoir en réalité plusieurs classes pour représenter
une donnée en particulier. Là si on prend notre exemple, on a le user entity, on a le user public
list DTO et le user create DTO par exemple, mais en plus on en aura même d'autres pour
chaque requête et réponse. Effectivement, on va venir recréer des nouvelles classes qui vont
simplement mapper des files, donc des attributs qui sont déjà existants, mais en réalité,
eh bien on est obligé de faire ça pour être vraiment conscient de ce qu'on récupère et de ce
qu'on envoie de notre serveur, donc c'est le genre de répétition de code qui est indispensable.
En conclusion, eh bien toutes les données qui naviguent entre vos services et votre base de données
sont des entités et tout ce qui passe par les requêtes HTTP de votre API sont des DTO,
des sous-ensemble sécurisés de vos entités. J'espère que cet épisode vous aura appris des
choses, que vous aurez peut-être carrément découvert le concept de DTO et qui vous pourra
vous accompagner toutes au long de votre vie de développeurs ou développeuses. Moi je vous retrouve
la semaine prochaine pour un prochain épisode du podcast ou directement sur code-garage.fr pour
retrouver tous les épisodes du podcast, tous les articles de blog qui sortent chaque semaine et
évidemment toutes nos formations pour continuer à vous former sur les sujets techniques dont vous
avez besoin. À la semaine prochaine, salut !