5 ms·

> Create a key-value pair > GET /?key=key&val=value GET is supposed to have no side effects, according to RFC2616 9.1.1.

m1sta_ 7y ago
I'll allow it.
afraca 7y ago
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...
- iCarrot 7y ago
  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.
  - phoe-krk 7y ago
    > 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 7y ago
      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 7y ago
        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 7y ago
        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 https://en.wikipedia.org/wiki/Web_beacon [2]: https://www.hitwebcounter.com/ https://www.hitwebcounter.com/
        oefrha 7y ago
        It's also "useful" for cross-site request forgery.
        iCarrot 7y ago
        Cross-site request forgery is only "useful" in auth context. There is no auth in Volatile, nor in the hit counter.
  - theon144 7y ago
    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 7y ago
      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.
- michaelmior 7y ago
  Unfortunately Volatile doesn't seem to support redirects.
brujoand 7y ago
Imagine doing a code review where someone wrote a function “getKeyValuePair” and it’s actually a method to post it. No :angry-no-face:
nexuist 7y ago
For a real world example of why idempotency is important and not just some random suggestion: https://twitter.com/rombulow/status/990684453734203392?s=21 https://twitter.com/rombulow/status/990684453734203392?s=21
- jlokier 7y ago
  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.
  - lordgrenville 7y ago
    Could you expand on this? I've read your comment a couple of times and still don't quite understand. How is it idempotent?
    - 33degrees 7y ago
      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
      - michaelmior 7y ago
        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.
        jlokier 7y ago
theon144 7y ago
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.
- phoe-krk 7y ago
  > 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?
  - deleted 7y ago
    [deleted]
newbold 7y ago
I've added a FAQ section to the site and have addressed this concern there.

m1sta_ 7y ago

I'll allow it.

afraca 7y ago

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

iCarrot 7y ago
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.
- phoe-krk 7y ago
  > 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 7y ago
    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 7y ago
      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 7y ago
        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 https://en.wikipedia.org/wiki/Web_beacon [2]: https://www.hitwebcounter.com/ https://www.hitwebcounter.com/
        oefrha 7y ago
        It's also "useful" for cross-site request forgery.
        iCarrot 7y ago
        Cross-site request forgery is only "useful" in auth context. There is no auth in Volatile, nor in the hit counter.
- theon144 7y ago
  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 7y ago
    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.
michaelmior 7y ago
Unfortunately Volatile doesn't seem to support redirects.

brujoand 7y ago

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

nexuist 7y ago

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

jlokier 7y ago
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.
- lordgrenville 7y ago
  Could you expand on this? I've read your comment a couple of times and still don't quite understand. How is it idempotent?
  - 33degrees 7y ago
    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
    - michaelmior 7y ago
      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.
      - jlokier 7y ago

theon144 7y ago

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.

phoe-krk 7y ago
> 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?
- deleted 7y ago
  [deleted]

newbold 7y ago

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