In theory there is no difference between practice and theory but in practice there is...
Seriously though this is the point I was making. There is nothing magic about REST that gives you reliability and resilience, it gives some hints but it still remains a job to be done to deliver on those expectations, saying that doing REST will mean that service automatically exhibit those properties isn't overly helpful and will lead to people becoming disillusioned with REST when their service fails. On 06/06/07, Peter Lacey <[EMAIL PROTECTED]> wrote:
> 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
