For a real world example of why idempotency is important and not just some random suggestion: https://twitter.com/rombulow/status/990684453734203392?s=21

Judging from the twitter thread, idempotency vs. safety is not widely understood.

The "create a key-value pair" operation described here actually is idempotent.

The requirement on GET is that it must be safe, meaning no side-effects, for a variety of reasons, not just browser behaviour.

The difference is described in detail in RFC 7231 section 4.2, or the older RFC 2616 section 9.1.

Could you expand on this? I've read your comment a couple of times and still don't quite understand. How is it idempotent?

Idempotent means that doing it once is the same as doing it more than once. This is standard terminology.

The parent comment uses "safe" to mean doing it zero times is the same as doing it once or more. This is not a definition I've heard before, but maybe it's common in this context. A more normal term would be "free of side effects".

"Safe" and "idempotent" have defined meanings in the HTTP standards, that's why I used those terms, and provided the RFC section that explains for anyone who cares to read more.

Idempotent means that a given request always has the same result. This GET request fits that definition, since making the same request several times will always return the same thing. The fact that it modifies data means that it’s not safe, but that is a different concern. Remember that PUT and DELETE are also idempotent

Of course it's not just that it returns the same result, but that the request has the same effect. This is not entirely true since the modification date will change, but other than that it's true that setting a key to the same value multiple times is idempotent.

If the modification date is changed, then its idempotency is open to application-specific definition.[1]

One way you might call modification time changes idempotent is if you don't care about modification times.

Another way is much subtler: Although an updated modification time represents a change, the point of HTTP idempotent requests is that repeating them automatically is harmless. This matters because some requests may be repeated automatically by some clients under some network conditions.[2] Updating the modification time twice to a near-current timestamp might satisfy the idempotency condition for the purposes of the application.

[1] This isn't as handwavy as it sounds. It means that because it's the application that determines whether the effects of a request count as "semantically" idempotent (or semantically safe), the application should choose the appropriate HTTP method (or "verb": GET, PUT, POST etc) for the application's needs. The application's choice of HTTP method matters because client libraries, proxies and servers perform different methods in different ways in the protocol.

[2] For example, if sent as the second or later request on a persistent HTTP/1.1 connection, just as the server closes the connection, then the client might retry any requests that are for an idempotent (or safe) method. So it may automatically retry GET, PUT and DELETE but not POST.

> One way you might call modification time changes idempotent is if you don't care about modification times.

My point exactly :)

Imagine doing a code review where someone wrote a function “getKeyValuePair” and it’s actually a method to post it. No :angry-no-face:

My initial response to your comment was "but then the page requires JS", which of course is not true, since a simple inline form could POST and then a redirect could get you back.

I'm no webdev, I think JS has been hyped so much around me I forgot plain html can actually do things...

Unfortunately Volatile doesn't seem to support redirects.

The correct response is "but then I need a webpage/separate tool".

When all API are GETs, the browser, which is likely to be open when you read this, is all you need.

Contrary to popular belief, the browser can perform POSTs as well as GETs.

An inline form on the webpage that POSTs the result is not a "webpage/separate tool". Option 2 would be to use the browser's dev console.

You need a webpage to have an inline form, which you need to create somehow. Compare that to just opening a new tab and type in an URL.

The dev console is a separate tool. And I'm still sure it is much quicker and easier to open a new tab and type in an URL, than to do a POST with dev console.

> When all API are GETs, the browser, which is likely to be open when you read this, is all you need.

And your service is also incorrect due to the issues with side-effects mentioned elsewhere in the thread.

It depends on how you interpret correctness. RFC 2616 9.1.1 also used "SHOULD NOT" and not "MUST NOT", indicating that there are valid use cases. The issue is about whether your users are aware of (and are responsible for) the side-effect or not. In this case they are.

Except when GET has side effects, one can embed the URL in an img tag and visitors would be triggering that side effect unknowingly. One can do this on most public forums. So no, users may not be aware.

What you just described is actually a web beacon [1], in which case the one that embed the URL is the user (and not the one who load the <img>). Web beacon can be used to implement useful thing like visitor counter service [2].

[1]: https://en.wikipedia.org/wiki/Web_beacon

[2]: https://www.hitwebcounter.com/

It's also "useful" for cross-site request forgery.

Cross-site request forgery is only "useful" in auth context. There is no auth in Volatile, nor in the hit counter.

Right; it's somewhat silly to suggest standard compliance to a service obviously not meant for any sort of serious use, but this irked me too.

> a service obviously not meant for any sort of serious use

Multiple existing and established services were created as proofs-of-concept, silly jokes, experiments, and other "non-serious use" projects. Many of them have survived and we are forced to bear with their sloppy design all the time.

Have you ever used e.g. JavaScript?

I've added a FAQ section to the site and have addressed this concern there.

I'll allow it.