« Visual Studio 2008 Tip: Resolving Namespaces and Removing Unused Using Statements | Main | New LINQ to XSD release »
06.02.08
REST & SOAP/WS-* - two different views
For a very long time I’ve been promoting the SOAP/WS-* way of developing web services. After many discussions, articles and posts on the REST/SOAP war and some experimenting on my own I finally tend to prefer the REST way. The main reason for doing so are the advantages of loosely coupling services when going the REST way.
The most important difference when designing RESTful and SOAP/WS-* web services is their view on models and processes. In my opinion REST demands a complete new way of designing services. Stefan provides a nice example of RESTful design on InfoQ.
Ganesh Prasad delves in the differences (or similarities) by setting up a Namespace-Time continuum, which should unify both approaches. Mark Baker responds and Ganesh updates his view.
Mark argues that “WS-* fails to separate interface from implementation, while REST does”. He provides an example task of changing the implementation of an interface and asks the question: “if I change the implementation of a component from a stock quote service to a weather report, does the interface have to change? If yes, then prima facie you haven’t decoupled interface from implementation, have you?”.
Ganesh responds:
Now, as an architect, I am rather sensitive to issues of tight coupling, and have often railed against examples of this, such as the SOAP-RPC style itself and the generation of WSDL files from Java implementation classes. But Mark goes much further. He would like to change the implementation of a service from a Stock Quote service to a Weather Report, and he would like to see his interface unchanged! To my mind, this goes beyond the reasonable.
I especially like and agree with his statement that Mark’s change is like “changing from pasta to soup, and expecting to continue using a fork”. It appears to me that both are talking about the same thing from a different perspective. Mark refers to the “technical” generic interface provided by REST only, whereas Ganesh concerns himself with the service design.
The RESTful approach demands a mapping of service design logic to a combination of HTTP/REST verb and URI. Every combination has to be interpreted in order to get its meaning. In most cases the meaning is obvious, in some it isn’t. Thus the RESTful service design has to put a strong emphasis on a very slick choice of meaningful URIs, especially when setting aside a service definition, such as WADL.
Posted by Hartmut Wilms at 06.02.08 12:17