[enjo]

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]

I cringe a little bit whenever someone tries to present caching as simple or straightforward.

[drivebyacct2]

I 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]

The 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

[Ramone]

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

[drivebyacct2]

I meant the HTTP spec which is where GETs specified.