> Mark> > > > That's actually not the case. That the server changes state as a > > > result of GET matters not to the RESTfulness of the system. > </Mark> > ... > <Pete> > > 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. > </Pete> > > So... Is GET supposed to be "safe" or not when it comes to REST? > > Regards, > > - Anil It goes like this: REST the style mandates a uniform interface. It does not say what that interface should be. It could, for instance, be read, write, update, order_lunch. And the semantics of the interface is up to the implementation. HTTP has a uniform interface; GET, PUT, POST, DELETE, etc., and HTTP suggests very strongly that GET be implemented safely. However it recognizes that some people want to make a non-safe GET, and thus tempers this suggestion by saying that if you do make a non-safe GET, then be aware that clients are free to call it willy-nilly, and if that screws things up, it's your fault.
So, from a purist POV, REST does not care that GET is safe or not, but from a practical POV, GET should be safe. - Pete
