On Thursday, June 07, 2007, at 11:33AM, "Eric Newcomer" <[EMAIL PROTECTED]> wrote:
>Certainly the design constraints in HTTP based systems are successful, but >those constraints also eliminate features/functions current enterprise systems >rely on (as was clearly stated at the Workshop). I cannot wait for that list (of features that enterprises rely on and REST eliminates). Will it be in the report? Jan > >If we had the luxury or ability to design and build all IT systems based on >HTTP, and throw out all existing investment in systems that did not obey the >REST constraints then perhaps we could use HTTP instead of WS-* for everything >(but even then I'm not sure since it was also clearly acknowledged at the >workshop and on this list that REST is not suited to every IT requirement). > >The fact is that people are getting real value out of both, and we really >really need to stop talking about this as if it were a "versus" and make it >into a "collaboration." > >Eric > > > >----- Original Message ---- >From: Peter Lacey <[EMAIL PROTECTED]> >To: [email protected] >Sent: Wednesday, June 6, 2007 3:18:09 PM >Subject: Re: [service-orientated-architecture] Anne on REST (Time for Spring >WS v. REST Campaign to Open) > >> 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. > >Sorry, that's wrong. A system that abides by the constraints enumerated >in the REST style will evince the properties associated with that >constraint relative to a system that does not. To use the caching >example again: There is a fixed cost in running the algorithm that >produces a message and there is a fixed cost in transmitting that >message over a network. If the algorithm is called twice, those costs >are assumed again. If the message is cached, however, the algorithmic >costs can be eliminated for future requests (until the cache gets stale) >resulting in better performance. Now, one could write a really bad >algorithm that runs in time X, and another person can write the same >algorithm that runs in time considerably less than X, but the algorithm >is outside the scope of REST. All other things being equal a system >that employs caching is more performant than one that does not. > >I have a feeling that you'll jump on the "all other things being equal" >bit, but see here: http://en.wikipedia .org/wiki/ Ceteris_paribus. How >else to analyze and predict the properties of complex systems? > >> 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). >The statelessness constraint is _solely_ about session (interaction) state. >> 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). >Exactly! Less things to go wrong means higher reliability. > >To be fair, and as recognized in the REST dissertation, each constraint >comes with a cost as well. For instance, statelessness, as you noted, >has a performance penalty in that information that could conceivably be >kept on the server now has to be in the message. To handle these >conflicts one has to (and Roy did) determine the level of impact that >the cost will have on the properties of the system you're trying to >bring about. If the cost is negligible, then it can be ignored. If >not, then it would be nice to offset it as much as possible. In the >case of statelessness, not only does statelessness offer greater >reliability but also visibility to external monitoring and scalability, >because state no longer has to be kept or managed (or shared) on the >server(s). Eliminating statelessness then has serious negative >implications. On the other hand the overall performance impact can be >mitigated by introducing caching, Since most systems are heavily biased >towards reads, the caching constraint more than makes up for what's lost >due to the statelessness constraint, resulting in a high-performing >system overall. > >- Pete > > > > > >____________________________________________________________________________________ >Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, >news, photos & more. >http://mobile.yahoo.com/go?refer=1GNXIC
