Salut et bienvenue dans ce nouvel épisode de Code Garage, je m'appelle Nicolas Brondant-Bernard
et aujourd'hui on va parler du principe d'idempotence en programmation.
Alors ce terme, on l'entend mais quand on connaît pas la définition, c'est très dur
de mettre justement un sens derrière ce mot puisque il ne ressemble pas vraiment à d'autres
choses, à d'autres mots qu'on connaît.
C'est normal, c'est un terme effectivement complexe qui vient tout droit du monde des
mathématiques et qui même s'il paraît compliqué de primes à bord, en fait il renferme une
signification qui est très très simple à définir.
On dit qu'une opération est idempotente si elle peut être répétée autant de fois
qu'on veut et que l'état des données en sortie ne change plus après la première
exécution.
On va prendre un exemple mathématique simple.
Normalement vous savez ce qu'est une valeur absolue.
Si on prend n'importe quel chiffre et qu'on lui met la valeur, on demande la valeur absolue,
ça sera une valeur qui sera toujours positive.
Si je demande la valeur absolue de 5, c'est 5.
Si je demande la valeur absolue de moins 5, c'est 5.
Ça revient tout simplement à avoir la valeur positive d'un nombre.
Donc qu'on ait un chiffre négatif en entrée ou qu'on ait un chiffre positif en entrée,
la sortie sera positive et il sera transformé la première fois qu'on va le faire passer
dans une fonction par exemple qui demande la valeur absolue.
Mais si on enchaîne cette fonction-là et qu'on demande la valeur absolue de la valeur
absolue de la valeur absolue, le résultat ne changera plus après la première exécution
parce qu'il est déjà positif et vous pouvez répéter l'opération à l'infini, il sera
toujours positif et le chiffre ne va pas changer.
Donc on dit que cette opération est idempotente.
Si je prends un exemple en dehors des mathématiques et que je prends un exemple de la vie réelle,
vous prenez un verre vide et vous le passez dans une fonction, on va parler d'une action,
on vous demande de remplir ce verre.
Vous prenez le verre, vous le mettez sous le robinet et vous le remplissez.
Ok ? Votre état final, c'est j'ai un verre rempli.
Maintenant, si je vous demande de refaire cette action-là, de remplir ce verre, même
si ce verre il est déjà rempli, si vous le mettez sous le robinet, l'eau va continuer
à couler, l'eau va déborder, ok ? Mais le verre, l'état final de m'aîdener l'état
du verre sera le même puisque le verre sera toujours rempli.
Il y aura de l'eau qui aura débordé, mais si on prend pas ça en compte, l'état
du verre n'a pas changé, on est passé d'un verre rempli, un verre rempli.
Pourtant, on a refait la même méthode, on a refait les mêmes actions, on a mis le verre
sous l'eau pendant un certain laps de temps et il est toujours rempli, l'action est donc
idempotente.
Alors en pratique, maintenant, à quoi ça correspond dans la programmation et dans l'informatique
en général ?
En algorithmie, il peut être spécifié qu'une fonction qu'on doit écrire pour x, y, et
c horrible, doit être idempotente.
Ça peut être pour des considérations techniques, ça peut être pour des considérations de
métiers, mais en gros, dès qu'on touche à des données au travers de cette méthode
là, il faut que les données de sortie même si on boucle sur cette fonction soient toujours
les mêmes. On a par exemple cet exemple-là très simple dans les appels HTTP. Alors pourquoi
dans les appels HTTP ? Par exemple, si on prend une API REST, c'est un très bon cas d'usage
pour présenter justement ce concept parce que les API REST sont basés sur des appels
HTTP et certaines méthodes de ce protocole sont spécifiées comme devant être idempotente.
Par exemple, les méthodes GET, PUT et DELETE ne doivent pas modifier l'état des données si
elles sont appelées plusieurs fois avec les mêmes paramètres. Le code de retour peut changer,
mais pas l'état des données. Je vous donne un exemple. Par exemple, une requête GET,
elle devra toujours envoyer les mêmes données sans modifier ces données-là. Donc normalement,
si je fais trois fois la même requête GET, je dois avoir trois fois le même résultat. Pourquoi ?
Tout simplement parce qu'on doit être en capacité aussi de pouvoir mettre en cache ces données.
Évidemment, les données, elles peuvent changer, mais le fait de faire appel à cette méthode GET ne
va pas changer les données à l'intérieur. Pour les requêtes PUT, les requêtes d'update,
de modification, normalement, si elles modifient toujours le même objet de la même façon,
en fait, l'état de l'objet sera altéré la première fois qu'on va appeler cette méthode PUT,
mais pas les prochaines fois. Les prochaines fois, l'objet ne sera pas modifié puisque c'est tout le
temps la même chose qui sera retourné. On demande à modifier les mêmes infos. Pareil pour la requête
DELETE, la requête DELETE, elle va supprimer la donnée en question. Et si on renvoie la même requête,
la ressource sera déjà été supprimée et donc ça renverra simplement une erreur 404,
par exemple, puisque l'objet n'existe plus, mais l'état global de vos données ne changera pas,
si vous l'appelez deux fois, puisque ça a déjà été supprimé. On ne va pas le supprimer une
deuxième fois, la donnée n'existe plus. Par contre, pour ce qui est de la méthode POST,
justement, cette dernière, théoriquement, et de DOIT pas être idempotente parce qu'on doit
pouvoir enregistrer plusieurs fois la même donnée pour diverses raisons. On peut, par exemple,
prendre l'exemple d'un log. Si on veut enregistrer un log, on peut avoir des logs qui ont quatre
fois la même valeur puisque c'est quatre fois la même action qui s'est passée et donc on doit
pouvoir avoir ces quatre objets bien distincts qui vont s'enregistrer dans notre AP. C'est un
exemple comme un autre. J'espère qu'avec un petit peu ces exemples-là, vous aurez compris le principe
de l'idempotence. Si on doit le résumer très simplement, une méthode qui est idempotente,
que vous l'appeliez une fois ou mille fois, le résultat sera toujours le même et ne changera pas
après la première exécution. J'espère que vous aurez appris quelque chose. J'espère que cet
épisode vous aura été utile et moi je vous dis à la semaine prochaine pour un épisode,
un nouvel épisode pardon, de Code Garage. Salut !