Oh no, not another permathread on REST! Ok Pete I thought we had addressed all this at the Web of Services for Enterprise Computing Workshop!
(Ok I know that we haven't finished the report, but I swear it will be out soon - I am working on it today in fact.) 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). 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
