On 03/06/07, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > On 6/3/07, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > Yup REST can indeed be used to deliver reliable systems, but I was > asking what about REST _guarentees_ reliability. So yes you can use REST and > then add on re-trys, use HTTP caching for non-time critical information and > set up either a resubmission approach or something very fancy to do "proper" > reliable messaging. But I'm really not sure which bit of REST (as opposed to > as you say decades old best practice) gives you the reliability. > > The stateless constraint, primarily. Any other architectural style > which uses that constraint will be similarly reliable.
But you can't be completely stateless, e.g. you have to save the fact that an order has been created, this means there is state. Having stateless interactions (as you say) is a way to remove certain classes of failure, but that is a long way away from being something special about REST. > > > > > N.B. I am NOT saying REST can't be reliable, but that using REST doesn't > mean that automagically a service will be reliable, which appeared to be the > implication earlier in the thread. > > It will be reliable in the sense that it will be as immune as a > service could be to network outages and other partial failures. I'd > say that counts as "automagically reliable". But that isn't actually very reliable, its just pretty much the same as everything out that is engineered to any basic level. Something like MQSeries and other "reliable" messaging products go quite a bit further in terms of adding in reliability around information exchange. > > Mark. >
