Idempotence (computer science)
From Wikipedia, the free encyclopedia
In computing, idempotence (IPA /ˈaɪdɛmˌpotn̩s/, like eye-DEM-potence) is the quality of something that has the same effect if used multiple times as it does if used only once, similar to the idempotence notion in mathematics.
An idempotent operation is one where no difference, errors or inconsistencies will result if the operation is carried out once, or many times.
Contents |
[edit] Example: Idempotent Header Files
C header files are often designed to be idempotent, that is, if the header file is included more than once (as can easily happen with nested #included files), then nothing untoward happens - the effect is the same as if a file had been included only once.
[edit] WWW behavior
HTTP GET requests are assumed to be idempotent [1]. The web infrastructure uses this assumption to cache the result of these requests.
Incorrect programming of a web site may sometimes lead to undesired behavior. In some cases, usually due to an incorrect or missing timestamp header, the software cannot correctly detect that the content of the requested page has been changed since the last request. Consequently, the local cache may need to be cleared. On most browsers, pressing reload will get a complete, non-cached update of the page on view. For others, a force reload is necessary. Note that these techniques will not clear intermediate caching servers, such as Microsoft ISA, Squid and other web caches. See below for more information on HTTP headers.
HTTP POST requests (usually used for user input forms) are not meant to be idempotent, so the result of a POST request is not cached.
HTTP POSTs are designed to submit information into the underlying system of the web site. For this reason it is bad design if they are used simply to hide URL data from the user, or simply to prevent caching. In the first case, hiding the data makes the site no more secure or error-proof, as any competent 'hacker' is able to alter the submitted POST data as easily as if it were visible in the URL. In the second case, caching is prevented by sending appropriate HTTP headers with each GET response to tell all the potential caches between the web server and the client's screen not to cache the data. For some examples of setting headers to prevent caching, see XMLHttpRequest.
Note that HTTP DELETE requests (a request to delete a resource at the specified URI) are also idempotent, since after a second DELETE request the resource at that URI will still be gone. "Idempotent" is frequently misinterpreted to mean an operation that causes no change to the entity being operated on. Such operations are called "safe" in HTTP.
[edit] NFS behavior
Designers of the Network File System protocol recognized that idempotent operations would help make the system more resilient in the face of server and network failures. Being stateless went along with this. Clients can repeat operations like Read and Write after a timeout without fear of corruption or incorrect results. The server or network can fail in between repeated operations, or the operations can go through. Either way, everything turns out fine. The original NFS RFC is careful to point out which operations are potentially non-idempotent, although many of them can be made idempotent with a trivial amount of server statefulness to detect repeated requests.
[edit] User interface
In user interface design, a button is "idempotent" if pressing it more than once will have the same effect as pressing it once. For example, a "Pause" button is not idempotent if it toggles the paused state. On the other hand, if pressing it multiple times keeps the system paused and pressing "Play", a different button, resumes, then "Pause" is idempotent. This is useful in interfaces such as infrared remote controls and touch screens where the user may not be sure of having pressed the button successfully and may press it again. Elevator call buttons are also idempotent (until the called elevator has arrived and redeparted), though some people behave as though they are not, pressing the button multiple times in the hopes that this will make the elevator arrive sooner.
Submit buttons on web forms may not be idempotent in all cases, except where measures have been taken to make them so. When shopping on line or internet banking, care must be taken not to order goods or make payments more times than intended. Some sites warn users textually not to click the button again until after the page has refreshed. Others have code built in, either client- or server-side to prevent second and subsequent presses from registering. Techniques can include quickly hiding or disabling the button client-side, or passing a unique code along with the other POST data so that server knows to reject subsequent POSTs of the same form. The latter case is particularly useful where a determined 'second-presser', or an unauthorised user, may use the browser's Back button to return to a previous form and resubmit it. To prevent anyone doing this, it is important always to close all browser windows after using internet banking or on-line shopping sites, especially in libraries, internet cafes and other public places.
