Editing Idempotence (section)

== Computer science meaning ==
{{See also|Referential transparency|Reentrant (subroutine)|Stable sort|Command query separation}}
In [[computer science]], the term ''idempotence'' may have a different meaning depending on the context in which it is applied:
* in [[imperative programming]], a [[subroutine]] with [[Side effect (computer science)|side effects]] is idempotent if multiple calls to the subroutine have the same effect on the system state as a single call, in other words if the function from the system state space to itself associated with the subroutine is idempotent in the mathematical sense given in [[#Definition|the definition]];
* in [[functional programming]], a [[pure function]] is idempotent if it is idempotent in the mathematical sense given in [[#Definition|the definition]].

This is a very useful property in many situations, as it means that an operation can be repeated or retried as often as necessary without causing unintended effects. With non-idempotent operations, the algorithm may have to keep track of whether the operation was already performed or not.

=== Computer science examples ===
A function looking up a customer's name and address in a [[database]] is typically idempotent, since this will not cause the database to change. Similarly, a request for changing a customer's address to XYZ is typically idempotent, because the final address will be the same no matter how many times the request is submitted. However, a customer request for placing an order is typically not idempotent since multiple requests will lead to multiple orders being placed. A request for canceling a particular order is idempotent because no matter how many requests are made the order remains canceled.

A sequence of idempotent subroutines where at least one subroutine is different from the others, however, is not necessarily idempotent if a later subroutine in the sequence changes a value that an earlier subroutine depends on—''idempotence is not closed under sequential composition''. For example, suppose the initial value of a variable is 3 and there is a subroutine sequence that reads the variable, then changes it to 5, and then reads it again. Each step in the sequence is idempotent: both steps reading the variable have no side effects and the step changing the variable to 5 will always have the same effect no matter how many times it is executed. Nonetheless, executing the entire sequence once produces the output (3, 5), but executing it a second time produces the output (5, 5), so the sequence is not idempotent.<!-- {{Citation needed|date=December 2017}} please discuss this on talk page before reinstating -->
<syntaxhighlight lang=c>
int x = 3;
void inspect() { printf("%d\n", x); }
void change() { x = 5; }
void sequence() { inspect(); change(); inspect(); }

int main() {
  sequence();  // prints "3\n5\n"
  sequence();  // prints "5\n5\n"
  return 0;
}
</syntaxhighlight>

In the [[Hypertext Transfer Protocol]] (HTTP), idempotence and [[Hypertext Transfer Protocol#Safe methods|safety]] are the major attributes that separate [[Hypertext Transfer Protocol#Request methods|HTTP methods]]. Of the major HTTP methods, GET, PUT, and DELETE should be implemented in an idempotent manner according to the standard, but POST doesn't need to be.<ref name="httpStd-methods">IETF, [http://tools.ietf.org/html/rfc7231#section-4.2.2 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content] {{webarchive|url=https://web.archive.org/web/20140608213403/http://tools.ietf.org/html/rfc7231 |date=2014-06-08 }}.  See also [[Hypertext Transfer Protocol|HyperText Transfer Protocol]].</ref> GET retrieves the state of a resource; PUT updates the state of a resource; and DELETE deletes a resource. As in the example above, reading data usually has no side effects, so it is idempotent (in fact [[wiktionary:nullipotent|''nullipotent'']]). Updating and deleting a given data are each usually idempotent as long as the request uniquely identifies the resource and only that resource again in the future. PUT and DELETE with unique identifiers reduce to the simple case of assignment to a variable of either a value or the null-value, respectively, and are idempotent for the same reason; the end result is always the same as the result of the initial execution, even if the response differs.<ref>{{cite IETF|title=Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |rfc=7231 |section=4.2.2 |sectionname=Idempotent Methods |quote=It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.}}</ref>

Violation of the unique identification requirement in storage or deletion typically causes violation of idempotence.  For example, storing or deleting a given set of content without specifying a unique identifier: POST requests, which do not need to be idempotent, often do not contain unique identifiers, so the creation of the identifier is delegated to the receiving system which then creates a corresponding new record.  Similarly, PUT and DELETE requests with nonspecific criteria may result in different outcomes depending on the state of the system - for example, a request to delete the most recent record. In each case, subsequent executions will further modify the state of the system, so they are not idempotent.

In [[event stream processing]], idempotence refers to the ability of a system to produce the same outcome, even if the same file, event or message is received more than once.

In a [[load–store architecture]], instructions that might possibly cause a [[page fault]] are idempotent. So if a page fault occurs, the [[operating system]] can load the page from disk and then simply re-execute the faulted instruction.  In a processor where such instructions are not idempotent, dealing with page faults is much more complex.<ref>
[[John Ousterhout]].
[https://web.stanford.edu/~ouster/cgi-bin/cs140-spring14/lecture.php?topic=paging "Demand Paging"].
</ref><ref>
Marc A. de Kruijf.
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.259.7708&rep=rep1&type=pdf "Compiler construction of idempotent regions and applications in architecture design"].
2012.
p. 10.
</ref>

When reformatting output, [[prettyprint|pretty-printing]] is expected to be idempotent. In other words, if the output is already "pretty", there should be nothing to do for the pretty-printer.{{Citation needed|date=March 2017}}

In [[service-oriented architecture]] (SOA), a multiple-step orchestration process composed entirely of idempotent steps can be replayed without side-effects if any part of that process fails.

Many operations that are idempotent often have ways to "resume" a process if it is interrupted{{snd}} ways that finish much faster than starting all over from the beginning. For example, [[upload#Resumability of file transfers|resuming a file transfer]], 
[[rsync|synchronizing files]],  creating a [[software build]], installing an application and all of its dependencies with a [[package manager]], etc.