<story><title>Idempotence: What is it and why should I care?</title><url>http://cloudingmine.com/idempotence-what-is-it-and-why-should-i-care/</url></story><parent_chain><item><author>rectangletangle</author><text>This is solid advice. Another common trick is to disable the submit event when the submit button is clicked for the first time, preventing two requests from firing, when the user double clicks. Then re-enable the event, if the request fails. Ideally this is done in addition to server side nonce validation, and not as the only preventative measure, because browser differences, or network issues could cause a double request (more likely if the HTTP GET method is used, instead of a proper POST). Regardless server and client side techniques should be used together to create a better UX, similar to using both client and server side email format validation.</text></item><item><author>ageitgey</author><text>This is vital if you are designing apis or clients that deal with charging a user money. It should be literally impossible for a user to accidentally get charged twice due to a flakey connection if you design correctly.&lt;p&gt;The trick is to have the client generate a random &amp;#x27;idempotency key&amp;#x27; (a uuid) to start each logical transaction and have the server use that id to prevent double charges of the same transaction. By always passing that key, client can request that the payment be processed a 100 times with no fear of it being processed more than once.&lt;p&gt;This stripe blog post has as good a description as any: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;stripe.com&amp;#x2F;blog&amp;#x2F;idempotency&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;stripe.com&amp;#x2F;blog&amp;#x2F;idempotency&lt;/a&gt;</text></item></parent_chain><comment><author>digitaLandscape</author><text>I don&amp;#x27;t like this because in practice sites usually fail to re-enable the submit button if something goes wrong. Just let the user submit multiple requests if they want to retry, don&amp;#x27;t take that away from them, just make it harmless.</text></comment>
<story><title>Idempotence: What is it and why should I care?</title><url>http://cloudingmine.com/idempotence-what-is-it-and-why-should-i-care/</url></story><parent_chain><item><author>rectangletangle</author><text>This is solid advice. Another common trick is to disable the submit event when the submit button is clicked for the first time, preventing two requests from firing, when the user double clicks. Then re-enable the event, if the request fails. Ideally this is done in addition to server side nonce validation, and not as the only preventative measure, because browser differences, or network issues could cause a double request (more likely if the HTTP GET method is used, instead of a proper POST). Regardless server and client side techniques should be used together to create a better UX, similar to using both client and server side email format validation.</text></item><item><author>ageitgey</author><text>This is vital if you are designing apis or clients that deal with charging a user money. It should be literally impossible for a user to accidentally get charged twice due to a flakey connection if you design correctly.&lt;p&gt;The trick is to have the client generate a random &amp;#x27;idempotency key&amp;#x27; (a uuid) to start each logical transaction and have the server use that id to prevent double charges of the same transaction. By always passing that key, client can request that the payment be processed a 100 times with no fear of it being processed more than once.&lt;p&gt;This stripe blog post has as good a description as any: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;stripe.com&amp;#x2F;blog&amp;#x2F;idempotency&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;stripe.com&amp;#x2F;blog&amp;#x2F;idempotency&lt;/a&gt;</text></item></parent_chain><comment><author>PinkMilkshake</author><text>That&amp;#x27;s only a partial solution. It may be a user agent or a queuing system (or anything else sitting between a person clicking the button and where the final transaction is recorded) that attempts a retry.</text></comment>