8 ms·
GET requests, by definition, should have no side-effects. Which makes them cacheable. Many browsers cache GET requests by default unless cache-control tells the
by enjo 14y ago
GET requests, by definition, should have no side-effects. Which makes them cacheable. Many browsers cache GET requests by default unless cache-control tells them not to.
You can most definitely write a GET request that contains side-effects, but that's because you're doing it wrong (tm).
Imagine if your function names had data in the call path MyCourse.32423.Delete(); that doesn't look very good does it? 32423 would look alot better inside Delete().
That's not data, that's an object. "MyCourse.32423" is the actual resource. It would actually look something more like:
MyCourse32423.Delete();
Which seems pretty reasonable to me if we're trying to map this into programming language semantics (which I'm not even sure we should be doing).
- Domenic_S 14y agoI cringe a little bit whenever someone tries to present caching as simple or straightforward.
- drivebyacct2 14y agoI don't see that anywhere in the post. All I saw was "GET"s shouldn't modify state and should be cacheable. That seems perfectly in line with the spec.
- jebblue 14y agoThe only problem I have with your comment is that REST is not specified, it's a style: http://en.wikipedia.org/wiki/Representational_state_transfer http://en.wikipedia.org/wiki/Representational_state_transfer
- Ramone 14y agoGET being cacheable/idempotent is part of the HTTP spec, and has nothing to do with REST: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.9 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...
- drivebyacct2 14y agoI meant the HTTP spec which is where GETs specified.