We have been having some discussions about how we approach a new application project, and the topic of REST vs SOAP was raised. I'd never heard of REST, but went for a surf and found quite a lot of interesting reading (see links below).
From what I have read, we were/are currently using a REST-style (I like the term RESTful) Architecture without having previously heard the term. The REST argument is that HTTP already has the appropriate methods (GET, POST, DELETE etc) to provide a complete and comprehensive interface for interaction. SOAP is a complex and superfluous addition which only increases verbosity and then requires WSDL to define interfaces for interaction. REST proponents argue that a simpler interface is as powerful, more comprehensible and is already in place. They quote the SQL syntax (SELECT, INSERT, UPDATE) to illustrate a relatively simple model that seems to suffice for data manipulation.
REST is not anti-XML, just anti-SOAP. We use GETs and POSTs to query and then return XML, but it is raw, not wrapped on a SOAP envelope.
As our applications are for internal use only, our approach, which we now recognise and some form of REST, does not need to provide discoverable interfaces. We do use Servlets and Java Agents to provide access via URLs, using GET and POST - these become the APIs. It then becomes relatively simple to recreate the URL on a different platform when the time comes.
Given that our current application server is Domino, we are using a RESTful architecture by default, as SOAP is not available on Domino. Don't tell me about the dodgy LotusScript SOAP client-only code, you can't have credible SOAP support without two-way support implemented in the product, not hand coded/decoded messages as an afterthought. The story here from IBM is well known by now - want the latest - get WebSphere.
Domino is becoming more of a clustered, replicating store to us. HTTP and XML allow is to server non-Notes clients pretty well. We will move on, eventually.
Joel covers the SOAP-boosters arguments well. He says:
Yes, SOAP is more complicated than URIs with XML responses, but only if you are the kind of person who hand codes your web services calls. The point of SOAP is that you use higher level languages to call it and to implement it and then it's easier and better and typesafe and all that good stuff.We are hand coding our calls at the moment. Can't find the SOAP methods in Designer.
He then goes on to highlight the perennial technology hype rollercoaster that we all loathe and gleefully participate in:
Some more opinions:The real problem with SOAP is that it's the poster boy for Web Services, which are just the next step in a long line of technologies that has been way overhyped by bored trade rag editors and conference organizers and web pundits.
No comments:
Post a Comment