3 ms·

For the most part, I say "1000 times yes!" I love the general idea he expresses that developers MUST take the time to understand the giants on whose shoulders

For the most part, I say "1000 times yes!" I love the general idea he expresses that developers MUST take the time to understand the giants on whose shoulders they stand. To that end, I have one noteworthy point (more of a clarification) I think is worth making: > And, technically, you’re supposed to make sure GET requests are idempotent, meaning they can be repeated with no changes to a resource. So you should be able to hit Refresh all day on a GET request without causing any data change. I think it's important to note here that idempotence does not mean that the resource will never change. It means that the resource will not change as a result of a get request (barring some meta requests, for example `GET /my-last-http-request`). A resource can definitely change. I think the author would agree with me but found his language there a bit ambiguous. Allow me to quote the good reverened himself, Dr. Roy Fielding: > "More precisely, a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent. The values in the set may be resource representations and/or resource identifiers." (emphasis mine) [1] Immediately prior this quote he references "the weather for Los Angeles today" as an example of a resource complete with its own resource identifier (perhaps GET /weather/la/today, most-to-least specific). The contents at the end of that URI will most certainly change, but they shouldn't ever change based on the request. [1] Section 5.2.1.1 https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...

teilo 12y ago
Yes, thank you. Every framework I have ever used maintains this distinction between GET and POST. It's common knowledge.
spb 12y ago
To hit the most important point of what you mean by "change based on the request", this doesn't mean "changing your request changing the resource you get" (which wouldn't make any sense). It means that the act of GETting the weather right now will never change the weather. (If you want to change the weather via HTTP, you'll need to do it with a method like "POST /weather/hill-valley" and a body like '{"rain": "stop"}'.) Think of it like a getter function that gets syntactically hidden by the language: you wouldn't want "if (user.accesses < limit || user.accesses > threshold )" to have two different values for "user.accesses" based on the number of times you referred to it. In a less ludicrous example, it also means "GET /tokens/reset/dsf46JtCb385PDs2" shouldn't log you in and invalidate the token, something that most password-reset pages fail to comply with.

teilo 12y ago

Yes, thank you. Every framework I have ever used maintains this distinction between GET and POST. It's common knowledge.

spb 12y ago

To hit the most important point of what you mean by "change based on the request", this doesn't mean "changing your request changing the resource you get" (which wouldn't make any sense). It means that the act of GETting the weather right now will never change the weather. (If you want to change the weather via HTTP, you'll need to do it with a method like "POST /weather/hill-valley" and a body like '{"rain": "stop"}'.) Think of it like a getter function that gets syntactically hidden by the language: you wouldn't want "if (user.accesses < limit || user.accesses > threshold )" to have two different values for "user.accesses" based on the number of times you referred to it. In a less ludicrous example, it also means "GET /tokens/reset/dsf46JtCb385PDs2" shouldn't log you in and invalidate the token, something that most password-reset pages fail to comply with.