On 06/06/07, Peter Lacey <[EMAIL PROTECTED]> wrote: > > > > > > > > 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. > Nothing is magic. Anything can be done poorly. So, yes, it's > ultimately up to the developer--as everything is. But if your > application _does_ obey REST principles (which is what is implied by > "doing REST"), then, yes, it surely does exhibit the properties stated > earlier.
No... it MIGHT exhibit them. You can obey the principles of REST and still create a pig. > If you obey the statelessness constraint, for instance, then > your application is more reliable because it can be instantiated > redundantly without the brittleness of sharing session information > across servers, and thus become more resistant to partial failure. It will also be either completely useless (if there really is no state) or insecure and unreliable (if all state is retained on the clients). Statelessness of interaction is one thing, having no state at all isn't viable (if I place an order I expect you to remember it). Security becomes a little bit tough as well if every request has to be individually authenticated with no caching of credentials. A level of statelessness helps in lots of cases, but it doesn't mean the service is now reliable, just that there are less things to go wrong (which is a good thing). > If > your application obeys the cacheability constraint, then, by definition, > your application is more performant. It goes on like that. Agreed, and caching is one of the truly nice bits around HTTP. But caching applies to certain sets of data and not all sets of data, so if I am doing medical monitoring then I'd really rather not cache the info for 15 minutes, I need the very latest info, hence REST doesn't help me. > > In contrast, since WS-* is without constraint, it can't be said to > exhibit any desirable property--whether done well or poorly. I'm not arguing that WS-* is better, and I've argued (in print) that there needs to be a WS-Contract and WS-SLA if you want to have proper SLA and Contract management and understanding from consumers as to what the level of service and QoS will be. REST and WS-* are implementation approaches, each have some nice things in the box around ilities (e.g. WS-Security et al for WS-* and Caching for REST) but reliability comes from the engineering of the solution for the requirements and demands at hand, not from picking an implementation approach. > > - Pete >
