Idempotence (computer science)
Encyclopedia : I : ID : IDE : Idempotence (computer science)
In computing, idempotence (IPA [ˈaɪdɛmˌpotns/, 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.
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.
A standard trick is to surround the whole text of the includable file by #ifndef/#endif directives:
/* File: sample_header.h
*/
#ifndef UNIQUE_PREPROCESSOR_CONSTANT
#define UNIQUE_PREPROCESSOR_CONSTANT
/* Here goes the material content of the file */
#endif
WWW behavior
HTTP GET requests are defined to be idempotent. The web infrastructure makes this assumption and often caches 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. If there is a suspicion of this happening, the local cache may need to be cleared. On most browsers, pressing Ctrl-F5 will get a complete, non-cached update of the page on view. For others, Shift-F5 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 whether data should be cached or not. For some examples of setting headers to prevent caching, see XMLHttpRequest.
Note that HTTP DELETE requests are also idempotent, since deleting an object twice has the same effect as deleting it once. This point is worth making because some people misinterpret "idempotent" to mean an operation that causes no change at all to the entity being operated on; which causes confusion when communicating with people who think that "idempotent" means idempotent.
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.
See also
From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.