[iCarrot]

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.

[theon144]

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.

[iCarrot]

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.

[phoe-krk]

> 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.

[iCarrot]

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.

[oefrha]

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.

[iCarrot]

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/

[oefrha]

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

[iCarrot]

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