Eric, During the last two days the discussion has become a bit more fervently religious in nature, but I still think the conversation is useful and informative. Steve's and Ash's questions indicate that not everyone understands the REST constraints, what benefits they provide, and what it means to be RESTful. It's hard to make a choice between method-oriented and RESTful is you don't understand the architectural style.
Fielding's dissertation<http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm>isn't that long, and I encourage people with questions to read it. Here are some additional resources: http://atmanes.blogspot.com/2007/06/how-not-to-do-restful-web-services.html http://www.xfront.com/REST-Web-Services.html Anne On 6/7/07, Eric Newcomer <[EMAIL PROTECTED]> wrote:
Yes it will, but it is very simply put - the design constraints for REST that promote its scalability eliminate features/functions enterprise IT systems rely upon, especially the shared session state mechanism (shared session state being among the items REST eliminates but of course cookies provide this for Web based applications, WS-Context for WS-*) that allows secure conversations, reliable message exchanges, failover/high availability mechanisms, transactions, etc. Now can we please stop this endless series of claims that one approach is always superior to another? That just isn't the case since it always depends on what someone is trying to accomplish. The fact is that people are getting value out of both REST and WS-*, despite the kind of personal bias or religious views that characterize this "debate." This obsession with fixed interfaces is also something that I hope everyone realizes is just another design choice. Fixed interface systems have been around since the start of computing - file systems, database management systems, etc. And so have custom interfaces. Some systems work better with one or the other, there are no absolutes here, if there were this would have been settled long ago. So can we please stop? ;-) Eric ----- Original Message ---- From: Jan Algermissen <[EMAIL PROTECTED]> To: [email protected] Cc: [email protected] Sent: Thursday, June 7, 2007 5:39:33 AM Subject: Re: [service-orientated-architecture] Anne on REST (Time for Spring WS v. REST Campaign to Open) On Thursday, June 07, 2007, at 11:33AM, "Eric Newcomer" <[EMAIL PROTECTED] com <e_newcomer%40yahoo.com>> 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] que.com<placey%40wanderingbarque.com> > >To: service-orientated- architecture@ yahoogroups. com<service-orientated-architecture%40yahoogroups.com> >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<http://mobile.yahoo.com/go?refer=1GNXIC> ------------------------------ Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge <http://us.rd.yahoo.com/evt=47093/*http://tv.yahoo.com/collections/222>to see what's on, when.
