When SOAP came into being as a means of powering Web services, it quickly became associated with SOAP RPC, a variation on existing distributed computing paradigms that used remote procedure calls. At the same time, Web services added a host of WS* standards that met different enterprise computing needs – authentication, security and the like. An alternative mechanism was waiting in the wings. That is representational state transfer, or REST. SearchSOA.com continues to update its REST software coverage.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In 2000, Roy Fielding, an author of the HTTP spec, wrote about "representational state transfer" or "REST"; his treatise was in some part a reaction to Web services as they were then concocted. He called for a simpler approach, more, perhaps, in harmony with the notion of the Web. Over the years it has proved influential, and has come to stand for a movement away from 'classic' SOAP-based Web services.
REST calls for use of HTTP without adding additional messaging layers or session tracking.
When the Web happened, its 'statelessness' was seen as a flaw by experts in established computer architectures in which maintaining state was vitally important. Today, at least among REST proponents, that 'flaw' is seen as a beneficial feature. Go figure!
For his part, William Brodgen writes that REST should be seen essentially as a philosophy of Web service architecture, not a standard like SOAP. Emphasis is on strict interpretation of the roles of the various actions; GET, PUT, POST and DELETE and the other features defined in the HTTP 1.1 protocol. He discusses this and more in ''Descriptive Languages for RESTful Services''.
The push to do RPC on SOAP was natural for the time. Transactions were king. Transactions are vital still, but they are changing in nature. What is the difference between RESTful transactions and Web Services transactions? That was a question we asked Eric Newcomer who said the question really pertains to global transactions -- those that involve more than one database, potentially on different computers. Newcomer, like Brodgen, emphasizes that REST is more an architectural approach, and less a technology. Newcomer discusses the issues in ''What is the difference between RESTful transactions and Web Services transactions?''
At the end of day still there is testing to be done. Tools once focused on WSDL work are now getting updated to include REST coverage via WADL support. Count among these soapUI. The 2.5 version of soapUI is said to include WADL generation. Also, soapUI 2.5 will allow testing of both XML and JSON output from RESTful Web Services. You can read about it in ''Use the soapUI software tool to tame WSDL,'' in SearchSOA.com's Tips section.
The value of REST architecture is that it takes better advantage of Web architecture, indicated Bill Burke, RedHat Fellow, and former Chief Architect for JBoss, certainly one of the most startlingly successful open-source Java implementations of all time. Burke is now Contributor to JBoss and a Project Lead on the JBoss RESTEasy Project. He provides a walk-through on aspects of using REST and Java in a presentation, ''Putting Java to Rest,'' from TheServerSide Java Symposium in March 2009. [This is a PDF document.]
Meanwhile, SearchWinDevelopment editor Yuvall Shavitt says REST is finding a place among the emerging group of Silverlight Rich Internet Application developers. That includes .NET developers using Moonlight, the Linux port of Silverlight. He discusses these trends in ''Moonlight and RIA client-server protocols: drop the SOAP, you are under a REST.''