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.
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. On 03/06/07, Mark Baker <[EMAIL PROTECTED]> wrote:
On 6/2/07, Steve Jones <[EMAIL PROTECTED]<jones.steveg%40gmail.com>> wrote: > To say that something that works over HTTP will exhibit "reliability" > sounds a little bit odd, given that HTTP is by design an unreliable > protocol. REST concerns itself with properties of an architecture as a whole, not of individual features of the system. It has been understood for decades, that it is possible to build reliable systems with unreliable messages. Mark.
