En informatique, une opération idempotente est une opération qui n'a pas d'effet supplémentaire si elle est appelée plusieurs fois avec les mêmes paramètres d'entrée. Par exemple, la suppression d'un élément d'un ensemble peut être considérée comme une opération idempotente sur l'ensemble.
En mathématiques, une opération idempotente est une opération où f (f (x)) = f (x) . Par exemple, la fonction abs() est idempotente car abs(abs(x)) = abs(x) pour tout x.
Ces définitions légèrement différentes peuvent être réconciliées en considérant que x dans la définition mathématique représente l’état d’un objet et que f est une opération qui peut muter cet objet. Par exemple, considérons le Python set et sa méthode discard. La méthode discard supprime un élément d'un ensemble et ne fait rien si cet élément n'existe pas. Alors:
my_set.discard(x)
a exactement le même effet que d'effectuer deux fois la même opération:
my_set.discard(x)
my_set.discard(x)
Les opérations idempotentes sont souvent utilisées dans la conception de protocoles de réseau, dans lesquels il est garanti qu'une demande d'exécution d'une opération se produit au moins une fois, mais peut également se produire plusieurs fois. Si l'opération est idempotente, il n'y a aucun mal à effectuer l'opération deux fois ou plus.
Voir l'article Wikipedia sur idempotence pour plus d'informations.
La réponse ci-dessus contenait auparavant des exemples incorrects et trompeurs. Les commentaires ci-dessous écrits avant avril 2014 font référence à une version antérieure.
Une opération idempotente peut être répétée un nombre arbitraire de fois et le résultat sera le même que s'il avait été effectué une seule fois. En arithmétique, ajouter zéro à un nombre est idempotent.
On parle beaucoup d'idempotence dans le contexte des services Web "RESTful". REST cherche à exploiter au maximum HTTP pour donner aux programmes un accès au contenu Web. Il est généralement différent des services Web basés sur SOAP, qui ne font que canaliser les services de style d'appel de procédure distante dans les demandes et les réponses HTTP.
REST organise une application Web en "ressources" (comme un utilisateur Twitter ou une image Flickr), puis utilise les verbes HTTP de POST, PUT, GET et DELETE pour créer, mettre à jour, lire et supprimer ces ressources.
L'idempotence joue un rôle important dans REST. Si vous obtenez une représentation d'une ressource REST (par exemple, GET une image JPEG de Flickr) et que l'opération échoue, vous pouvez simplement répéter l'opération GET encore et encore jusqu'à ce que l'opération réussisse. Pour le service Web, le nombre de fois où l’image est obtenue n’importe pas. De même, si vous utilisez un service Web RESTful pour mettre à jour les informations de votre compte Twitter, vous pouvez insérer les nouvelles informations autant de fois que nécessaire pour obtenir une confirmation du service Web. METTRE-le mille fois est la même chose que le mettre-une fois. De même, supprimer une ressource REST mille fois équivaut à le supprimer une fois. Idempotence facilite donc considérablement la création d’un service Web résistant aux erreurs de communication.
Pour en savoir plus: Services Web RESTful , de Richardson et Ruby (l’impuissance est décrite à la page 103-104), et de Roy Fielding Thèse de doctorat sur REST . Fielding était l’un des auteurs de HTTP 1.1, RFC-2616, qui parle d’idempotence dans la section 9.1.2 .
Peu importe le nombre d'appels que vous appelez l'opération, le résultat sera le même.
Idempotence signifie qu'appliquer une opération une fois ou plusieurs fois a le même effet.
Exemples:
- Multiplication par zéro. Peu importe le nombre de fois que vous le faites, le résultat est toujours nul.
- Définir un drapeau booléen. Peu importe combien de fois vous le faites, le drapeau reste en place.
- Supprimer une ligne d'une base de données avec un identifiant donné. Si vous réessayez, la ligne est toujours partie.
Pour fonctions pures (fonctions sans effets secondaires), idempotency implique que f(x) = f(f(x)) = f(f(f(x))) = f(f(f(f(x)))) = ...... pour toutes les valeurs de x
Pour fonctions avec effets secondaires, idempotency implique en outre qu’aucun autre effet indésirable ne sera provoqué après la première application. Vous pouvez considérer l'état du monde comme un paramètre "caché" supplémentaire à la fonction si vous le souhaitez.
Notez que dans un monde où vous avez des actions simultanées, vous pouvez constater que les opérations que vous pensiez idempotentes cessent de l'être (par exemple, un autre thread pourrait annuler la valeur de l'indicateur booléen dans l'exemple ci-dessus). Fondamentalement, chaque fois que vous avez accès simultané et qu’il est mutable, vous devez réfléchir plus attentivement à l’idempotency.
L'idempotence est souvent une propriété utile dans la construction de systèmes robustes. Par exemple, si vous risquez de recevoir un message en double d'un tiers, il est utile que le gestionnaire de messages agisse comme une opération idempotente afin que l'effet du message ne se produise qu'une seule fois.
Une opération idempotente produit le résultat dans le même état même si vous l'appelez plusieurs fois, à condition que vous transmettiez les mêmes paramètres.
Je voulais juste jeter un cas d'utilisation réel qui démontre l'idempotence. En JavaScript, supposons que vous définissiez un ensemble de classes de modèle (comme dans le modèle MVC). La manière dont cela est souvent implémenté est fonctionnellement équivalente à quelque chose comme ceci (exemple de base):
function model(name) {
function Model() {
this.name = name;
}
return Model;
}
Vous pouvez ensuite définir de nouvelles classes comme ceci:
var User = model('user');
var Article = model('article');
Mais si vous essayiez d'obtenir la classe User via model('user'), ailleurs dans le code, cela échouerait:
var User = model('user');
// ... then somewhere else in the code (in a different scope)
var User = model('user');
Ces deux constructeurs User seraient différents. C'est,
model('user') !== model('user');
Pour le faire idempotent, vous ajouteriez simplement une sorte de mécanisme de mise en cache, comme ceci:
var collection = {};
function model(name) {
if (collection[name])
return collection[name];
function Model() {
this.name = name;
}
collection[name] = Model;
return Model;
}
En ajoutant la mise en cache, chaque fois que vous avez fait model('user'), ce sera le même objet, il est donc idempotent. Alors:
model('user') === model('user');
Une opération idempotente est une opération, une action ou une demande pouvant être appliquée plusieurs fois sans modifier le résultat, c'est-à-dire l'état du système, au-delà de l'application initiale.
EXEMPLES (CONTEXTE WEB APP):
IDEMPOTENT: Faire plusieurs demandes identiques a le même effet que faire une seule demande. Un message dans un système de messagerie électronique est ouvert et marqué comme "ouvert" dans la base de données. On peut ouvrir le message plusieurs fois, mais cette action répétée ne fera que rendre ce message à l'état "ouvert". C'est une opération idempotente. La première fois que l'on PUT une mise à jour d'une ressource en utilisant des informations qui ne correspondent pas à la ressource (l'état du système), l'état du système change à mesure que la ressource est mise à jour. Si un PUT effectue la même mise à jour de manière répétée sur une ressource, les informations de la mise à jour correspondent aux informations déjà présentes dans le système à chaque PUT et aucune modification de l'état du système ne se produit. Les PUT répétés avec les mêmes informations sont idempotents: le premier PUT peut changer l'état du système, les PUT suivants ne le devraient pas.
NON-IDEMPOTENT: Si une opération provoque toujours un changement d'état, comme POST le même message à un utilisateur, ce qui entraîne l'envoi et le stockage d'un nouveau message dans la base de données à chaque fois, on dit que l'opération est NON-IDEMPOTENTE.
NULLIPOTENT: Si une opération n'a pas d'effets secondaires, comme afficher uniquement des informations sur une page Web sans aucune modification dans une base de données (en d'autres termes, vous ne lisez que la base de données), nous disons que l'opération est NULLIPOTENT. Tous les GET doivent être nullipotents.
Lorsque nous parlons de l'état du système, nous ignorons évidemment des effets inoffensifs et inévitables, tels que la journalisation et les diagnostics.
Opérations idempotentes: Opérations qui n'ont aucun effet secondaire si elles sont exécutées plusieurs fois.
Exemple: Opération qui extrait les valeurs d'une ressource de données et les imprime
Opérations non idempotentes: Opérations qui causeraient un préjudice si elles étaient exécutées plusieurs fois. (Comme ils changent certaines valeurs ou états)
Exemple: Une opération qui se retire d'un compte bancaire
Des réponses assez détaillées et techniques. Je viens d'ajouter une définition simple.
Idempotent = Réexécutable
Par exemple, il n'est pas garanti que l'opération Create en elle-même s'exécute sans erreur si elle est exécutée plusieurs fois. Mais s'il existe une opération CreateOrUpdate, elle indique alors la possibilité d'exécution (Idempotency).
C'est n'importe quelle opération que chaque nième résultat produira une sortie correspondant à la valeur du 1er résultat. Par exemple, la valeur absolue de -1 est 1. La valeur absolue de la valeur absolue de -1 est 1. La valeur absolue de la valeur absolue de la valeur absolue de -1 est 1. Et ainsi de suite.
Voir aussi: Quand serait-il vraiment idiot d'utiliser la récursivité?
Une opération idempotente sur un ensemble laisse ses membres inchangés lorsqu’elle est appliquée une ou plusieurs fois.
Ce peut être une opération unaire comme absolute (x) où x appartient à un ensemble d’entiers positifs. Ici absolu (absolu (x)) = x.
Ce peut être une opération binaire comme l'union d'un ensemble avec lui-même renverrait toujours le même ensemble.
à votre santé
mon 5c: Dans l'intégration et la mise en réseau, l'idempotency est très important. Plusieurs exemples tirés de la vie réelle: Imagine, nous transmettons des données au système cible. Données livrées par une séquence de messages. 1. Que se passerait-il si la séquence est mélangée dans le canal? (Comme le font toujours les paquets réseau :)). Si le système cible est idempotent, le résultat ne sera pas différent. Si le système cible dépend du bon ordre dans la séquence, nous devons implémenter resequencer sur le site cible, ce qui permettrait de restaurer le bon ordre. 2. Que se passerait-il s'il y avait des doublons de messages? Si le canal du système cible n'accuse pas réception dans les délais, le système source (ou le canal lui-même) envoie généralement une autre copie du message. En conséquence, nous pouvons avoir un message en double du côté du système cible. Si le système cible est idempotent, il s'en occupe et le résultat ne sera pas différent. Si le système cible n'est pas idempotent, nous devons implémenter le déduplicateur du côté système cible du canal.
En bref, Opérations idempotentes signifie que l'opération n'entraînera pas des résultats différents, quel que soit le nombre d'opérations idiopotentes.
Par exemple, selon la définition de la spécification de HTTP, GET, HEAD, PUT, and DELETE sont des opérations idempotentes; cependant POST and PATCH ne le sont pas. C'est pourquoi parfois POST est remplacé par PATCH.