<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom"><title>Simon Willison's Weblog: idempotency</title><link href="http://simonwillison.net/" rel="alternate"/><link href="http://simonwillison.net/tags/idempotency.atom" rel="self"/><id>http://simonwillison.net/</id><updated>2017-10-27T17:51:52+00:00</updated><author><name>Simon Willison</name></author><entry><title>Implementing Stripe-like Idempotency Keys in Postgres</title><link href="https://simonwillison.net/2017/Oct/27/stripe-like-idempotency-keys-in-postgres/#atom-tag" rel="alternate"/><published>2017-10-27T17:51:52+00:00</published><updated>2017-10-27T17:51:52+00:00</updated><id>https://simonwillison.net/2017/Oct/27/stripe-like-idempotency-keys-in-postgres/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="https://brandur.org/idempotency-keys"&gt;Implementing Stripe-like Idempotency Keys in Postgres&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Having clients send “idempotency keys” with API requests in order to be able to safely retry them if something’s goes wrong is a really neat trick for making transactional APIs more robust. Here Brandur Leach talks implementation strategies.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="https://news.ycombinator.com/item?id=15569478"&gt;Hacker News&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/api-design"&gt;api-design&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/idempotency"&gt;idempotency&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/postgresql"&gt;postgresql&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/brandur-leach"&gt;brandur-leach&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/stripe"&gt;stripe&lt;/a&gt;&lt;/p&gt;



</summary><category term="api-design"/><category term="idempotency"/><category term="postgresql"/><category term="brandur-leach"/><category term="stripe"/></entry><entry><title>REST, I just don't get it</title><link href="https://simonwillison.net/2008/Aug/15/katz/#atom-tag" rel="alternate"/><published>2008-08-15T08:20:04+00:00</published><updated>2008-08-15T08:20:04+00:00</updated><id>https://simonwillison.net/2008/Aug/15/katz/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://damienkatz.net/2008/08/rest-i-just-dont-get-it.html"&gt;REST, I just don&amp;#x27;t get it&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Read the comments for some excellent practical reasons to care about REST, including cache management (PUT and DELETE can expire the cache entries for the corresponding GET), the ability to add or move parts of the server API without redeploying client libraries and the idempotency of GET / PUT / DELETE and HEAD (repeated POST operations may have side-effects).


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/caching"&gt;caching&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/damien-katz"&gt;damien-katz&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/delete"&gt;delete&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/get"&gt;get&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/idempotency"&gt;idempotency&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/post"&gt;post&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/put"&gt;put&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/rest"&gt;rest&lt;/a&gt;&lt;/p&gt;



</summary><category term="caching"/><category term="damien-katz"/><category term="delete"/><category term="get"/><category term="idempotency"/><category term="post"/><category term="put"/><category term="rest"/></entry></feed>