Linking Web service requesters and providers entails a fair amount of work for both parties, encompassing such things as agreeing on the business function to be fulfilled, the technical contract details and of course integrating the service into the grander scheme of an application. But far too often using the standardized SOAP/WSDL approach becomes overly complex in such scenarios.
There is an alternate approach to deploying a Web services compliant architecture named REST, Representational State Transfer. REST is a technique coined by Roy Fielding in the year 2000 during what was his doctoral dissertation, While it is questionable if he had the prescience to create an approach that would compete head-to-head with industry heavyweights and consortium specifications, since then the REST acronym has come to center stage in Web services design.
What is it about REST that makes it different from standard SOAP/WSDL? The simplicity in shedding some of the heavyweight requirements needed in the latter approach, which on many occasions prove unnecessary to achieving the basic functionality of a Web service.
In order to gain a little more perspective on REST, let's recap a typical process for a SOAP/WSDL design:
1 - Provider creates and implements a Web service interface onto an existing application.
2 - Provider creates a WSDL contract in order to distribute the Web service details to potential consumers.
3 - Consumer obtains WSDL contract for consumption.
4 - Consumer implements the WSDL in a specific platform - Java, C#, PHP, Perl - and creates a caller application.
The biggest rub in this process lies on the consumer. Not only will he have to deal programatically with extracting the Web service payload -- e.g. the SOAP message -- in order to do something useful with it in the application, but he will also need to go the extra mile also programmatically, through WSDL, to do the initial service request...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
in order to get the payload. If you have gone through this process on various occasions like many, you probably accept it as a given fact when dealing with Web services. Yet this process can often prove to be overkill, so lets take a step back to the essence of a Web service.
The main reason Web services are on many IT department's agendas is quite simple: To achieve interoperability between disparate systems, for instance an SAP ERP communicating with a Java application or a PHP Web site connecting to a .NET news service. With this definition in hand, let's analyze a very common service which complies with this interpretation and uses REST at its core, Atom and RSS news feeds.
Initially conceived in the blogsphere and now on pretty much every mainstream site, a news feed allows a provider to publish site updates and a consumer to fetch such updates in an on-demand fashion. Behind the scenes, a provider site can be built in Java, PHP or Perl while providing an XML payload formatted as either RSS or Atom. The update can later be consumed by an application also written in any language.
A quick glance around the Web can show you the extent of news feeds. There are a multitude of applications (consumers) that aggregate RSS data feeds from around the Net to provide enriched content, all taken from third party services.
The process is straightforward and can actually be more flexible than just providing the read functionality that RSS/Atom services offer. Since a REST process is executed within the context of HTTP, all of its operators -- get, post, put and delete -- are on hand to achieve whatever business function needs to be fulfilled.
If you are still somewhat skeptical about the concept behind REST thinking it's more academic or that RSS and Atom news feeds are an isolated scenario, let's look at more production type applications that use REST.
eBay's REST API allows developers to tap into its numerous sources of information in order to integrate this same data onto third party applications. Yahoo's Web services offerings are also strongly rooted on REST, so much that they currently don't even offer SOAP support. Yahoo only uses REST.
These few examples should give you a feel for how REST developed Web services have a strong community backing, but hold on, just like every technique REST also has its shortcomings. If there is a common thread among REST Web services it's the non-vital nature of the data they handle.
Transporting more sensitive data through applications such as financial data or procurement information requires the use of more sophisticated features like transactions, failover capabilities and quality of service. Given REST's simplicity that can prove to be a complicated undertaking. Not that this last scenario is impossible to achieve through REST, but under these types of enterprise requirements the design balance starts to tilt in favor of the heavier-weight SOAP/WSDL approach.
SOAP, through its series of complementary specs such as WS-Policy, WS-Security, WS-Reliabilty and WS-TranscationManagement among others, gives you a clear roadmap on how to address these issues from the outset whereas in REST these issues become more complicated to integrate into an application.
Although REST is not appropriate for every scenario it can make creating and interacting with Web services much simpler. Given its wide deployment by major portals and its no-nonsense approach, it's a compelling approach to explore on your next Web services design undertaking.
About the Author
Daniel Rubio is an independent technology consultant specializing in enterprise and Web-based software, He blogs regularly on these and other software areas at http://www.webforefront.com.
