In his comment on my last post , Steve Vinoski warns against getting into “pseudo-religious technical debates like "REST vs. SOAP”. I agree.
However, for an enterprise architect implementing (or planning to implement) an SOA, the decision still has to be made as to what technology should be used – a decision which could have a considerable influence on the costs and success of any SOA initiative. Such a decision needs to be based on arguments which corporate management understands, rather than hearsay about what apparently works or does not.
The difficulty in making such architectural decisions is not on seeing what simply works. SOAP works, so does REST. Way back in the mists of time (i.e 1999) I worked on a project which used a REST style of communication between the client (an applet - remember those) and the server. I made the decision to use a simple HTTP interface as no other alternative existed then (according to Don Box, the SOAP spec only shipped in 4Q1999). It actually worked surprisingly well (and is still working to this day). REST can work in an enterprise environment.
The problems start when we come to architecture in the large. In large architectures other factors come into play, such as how to manage the interfaces in the face of changing requirements. As Steve mentions in his article "... some of the architects and developers I know who work on large SOA systems ... figured out the uniform interface constraint on their own, without ever hearing of REST". Developing generic interfaces does help, but how generic does an interface need to be?
In the REST model the generic interface supports the four interaction verbs described in the HTTP spec, i.e. GET, POST (equivalent to create), PUT (equivalent to update) and DELETE. However, taking one extreme it is possible to reduce POST, PUT and DELETE to one verb - MAINTAIN - and split the data payload into a before image (BI) and an after image (AI). Specifying the BI and leaving the AI empty is equivalent to a DELETE. Specifying the AI and leaving the BI empty acts like a create. Specifying both is an update, with the advantage that the system can check if the data has changed in the meantime by looking at the BI. Apart from database interfaces I haven't seen anything written about this technique in creating SOAs. I have, however, seen one system which implemented it in a web service context and with SOAP.
As the above example shows, you can still provide generic interfaces with the SOAP/WSDL combination as well as with REST. It seems to me that the SOAP vs. REST debate is arguing about the wrong things. It should about how to design interfaces rather than the technology used for their implementation.
