Michael Champion, a research and development specialist at Software AG, said "nasty enterprise integration problems" demand more sophisticated protocols and methods. In a blog posting, he called on backers of both approaches -- Web services and REST -- to make their cases as to why their approach is better.
Ron Schmelzer, an analyst at Web services research company ZapThink, said REST can indeed yield better results in isolated instances. But the method misses the overall point of Web services, where interoperability between products from different vendors is the ultimate goal.
"You can build whatever you want and optimise it behind your own firewall," Schmelzer said. "But if you want interoperability, then you have to agree to something. It's not meant to be optimal -- it's what companies can agree to do together, given that they have very different products."
Schmelzer noted that the advanced Web services protocols now under development are designed for thorny computing problems that demand complex protocols. For example, REST does not address aspects, such as security, reliable messaging, or business process automation in a standardised way, he noted.
Other Web services advocates argue that developers can be shielded from a great deal of complexity by the development tools they choose.
"If you don't understand all the specs, don't worry about it. Tools are being created by people everywhere to make it so you can just indicate the capabilities you need, and the rest will be done for you," said Matt Powell, a content strategist at Microsoft's developer network, in a posting.
Also, Web services advocates note that the specifications were designed so that the latest capabilities, such as reliable messaging and security, can work with applications that use simpler Web services standards, such as the transport protocol SOAP. Microsoft earlier this month published a white paper stating that Web service protocols are designed to be "autonomous," which allows developers to pick the level of sophistication they need.
Randy Heffner, an analyst at IT consulting company Forrester Research, noted that REST-style development is suited for relatively simple applications. But ultimately, corporations that want to reap the benefits of a flexible systems design called a services-oriented architecture should adopt Web services based on SOAP.
Heffner draws a parallel to the early days of Web services, where SOAP was meant to be a simpler method than CORBA, an older programming standard that never reached market ubiquity, in part because of its complexity. But as Web services become more mainstream, companies will need to exploit the advanced protocols embedded in the latest products.
"Given REST’s simpler technology stack, it is reasonable that it should be faster," Heffner said. "The pursuit of development productivity... adds overhead to SOAP and, in most cases, the overhead will be worth it."
Talkback
i am a new internet user. i am also a grandmother.if i thought a paedophile was using the internet to get through to my grandchildren i would hope that the people who are responsible for this site would tell the police. if not any paedophile.i.e dirty bastard i would kill.
Let's not kid ourselves about Web services and their potential, but let's also not lose sight of the fact most businesses are still asking what are 'web services'?
For technically illiterate managers, they're nothing more than EDI systems of yesterday dressed up in a new terminology. Unless someone can demonstrate, in a capable and coherent way what web services actually are, do and offer, businesses what know what they mean.
Whilst the IT profession pushes on, the meaning of web services becomes more and more diffuse. Neither Microsoft nor IBM can agree on a single standard definition in their corporate literature, and over-emphasise on the jargon far too much.
Yes, we've lost sight of what they're meant to do, and what the vendors say they can do.
Dave Hall is correct when it comes to "business oriented" web services. Furthermore, the same mistakes with EDI (which can mean whatever you want it to mean despite the existence of so-called "standards") are now being replicated in the wide variety of XML DTDs available.