For years now, proponents of REST-based Web services have been battling WS-* and SOAP proponents on which delivers the most agility to enterprises.

REST (XML over HTTP) is seen as a lightweight, highly adaptable protocol that can quickly link external services to applications. Amazon Web Services, for one, is a well-known repository of REST-based services (though AWS’ official stance is standards-neutral.)

REST is seen as a more agile approach to application mashups, the core of Enterprise 2.0 activity.

However, many observers have doubted whether REST can accomplish the heavy lifting of intra-application integration required within enterprises. SOAP and the emerging WS-* standards (such as WS-Security and WS-ReliableMessaging) are better suited to this purpose, they said.

Wounds were re-opened a little over a year ago, when Gartner’s Darryl Plummer pointed out in an oft-discussed article that the Web services world had actually split into two camps — the more complex SOA proponents, and the external Web app proponents. However, the lower complexity of external Web-facing apps may have something to offer internal deployments as well. “Standards such as Plain Old XML (POX) over HTTP and Representational State Transfer (REST) are asserting themselves as legitimate and very credible ways of delivering on the value proposition of Web services.”

Now, Burton Group’s Anne Thomas Manes agrees that the future may be a RESTful one. According to a report by TechTarget’s Rich Seeley, Anne recently told a conference that “REST is not new because REST is in fact the Web,” she said. “The Web has been around for 15 years, but very few people have used it for service-oriented systems.”

That may change soon.

REST is now starting to catch on in SOA, Anne observes. However, it’s only now being used by innovators, and it may take up to 10 years before a majority of developers will be using REST.

REST involves sending GET commands via HTTP to URIs to retrieve data. However, Anne said, “even long-time REST advocates admit having trouble thinking of applications in terms of REST.”

Help is on the way. Major vendors such as IBM and Microsoft — as well as open-source communities — are releasing frameworks and tools for designing and building REST applications. However, many tools are not ready, she added. “Web services toolkits that say they do REST don’t always [do it as advertised],” she said. “They do POX.”

Sam Ruby, who recently wrote a book on REST with Leonard Richardson, observed in a recent interview that “REST not the solution to every problem, but I will note that if you find a problem where REST is not the solution, it does not immediately follow that WS-* is either.”

In fact, the advantage REST holds over WS-* is its ability to support application mashups, Richardson said. A real plus for REST is “the control it gives the users of the service,” he pointed out. “If your data is exposed through a large number of resources, I can get to the data I want very quickly, using a minimal software stack you may not explicitly support. When resources are identified by URI, I can feed the URIs into other services to make mashups. When resources link to each other, I can navigate them without internalizing a lot of complicated rules.”

Ruby said in the interview that prior to his REST epiphany (thanks to the Blosxom code base), he had always “operated under the assumption that the network was something that needed to be encapsulated and abstracted away. And here was a small piece of code with no dependencies which actually was simpler, more powerful, more maintainable, and more robust because it did NOT make these assumptions.”