> That's actually not the case. That the server changes state as a > result of GET matters not to the RESTfulness of the system. Granted. While it is understood that a server may trivially change state (e.g., log files) on response to a GET. And it's also understood that what this best practice really implies is that the client can't be held responsible for any state change in response to a GET. When the rubber meets the road, if a server changes resource state in response to a GET, then it is at least in violation of the spirit of HTTP, and is very likely to not be RESTful -- as ECS and EC2 proved to be.
It's tricky to maintain the line in your head between architectural descriptions, implementations, and best practices.
