Daily Archives: October 4, 2004

Complexity in REST and SOAP

Ok, so let’s take a stab at the main question Pete raised in his comment to the previous blog entry, and which has generated some further comments. Hopefully this will generate further good and helpful discussion…
The main question as I understand it is what are the use cases for Web services as distinguished from the use cases for REST, and why would you use one or the other. Also when is the added complexity of Web services justified.
This is probably a bit of an over simplification, but to me the best summary is that you use REST when you want to display XML data in a browser, and you use SOAP when you want to pass XML data to a program.
The situation regarding the use of Amazon.com’s Web services is that last year, 80% of the developers used the XML over HTTP version and 20% used the SOAP version. This makes sense because most of Amazon.com’s users are interested in displaying the data in a browser in virtual storefronts. However, Amazon.com includes both flavors in its “Web services” since they also have developers interested in passing the data to programs. (For the sake of clarity I’ll adopt Amazon’s current terminology (REST and SOAP Web services).)
One way to look at REST is that it basically means putting Web service requests into the URL.
This the URL I get when I type “Skateboots” into Google.com’s search window:
http://www.google.com/search?hl=en&ie=UTF-8&q=%22Skateboots%22&btnG=Google+Search
Google basically takes my input to their Web form and appends it as parameters to their URL, with some other stuff about the character set and operation to be performed (i.e. “Search”), which executes their service and returns the results in my browser. Google also asks me if I meant “Skate Boots” (i.e. two words instead of one). This is the URL generated when I clicked on that link:
http://www.google.com/search?hl=en&ie=UTF-8&q=%22Skate+boots%22&spell=1
The recently released (August 2004) Web services V4 from Amazon.com continues to provide both REST and SOAP requests for its Web services. Now, some people would argue that REST and Web services are different things, while others would argue that you could do everything with REST that you can do with Web services. To me it seems like different formats for essentially the same operations.
The difference seems to boil down to whether or not you want to use a browser to interpret the result data. If you do, then you might as well use the REST requests (i.e. place the parameters in the URL). However, if you are interpreting the data in a program, then you should probably use the SOAP requests since the parameters are carried within the XML message (instead of in the URL).
This is the format Amazon gives for its REST based Web services requests:
http://webservices.amazon.com/onca/xml?Service=AWSECommerceService
&SubscriptionId=[your subscription ID here]
&Operation=ItemSearch
&SearchIndex=Books
&Keywords=dog
&ResponseGroup=Request,Small
After you get a subscription ID (I am sorry but I did not go so far as to obtain one) you can simply type the request parameters into the address box on your Firefox (or other) browser, hit return, execute it, and view the XML results. Nothing could be simpler.
But if you wanted to send the XML data to a program, possibly using another transport, the SOAP request format will do the job better since it’s designed for that, and everything the message needs is within the envelope (i.e. no dependence on transport features such as fixed interfaces and URL parameters). With the REST request it’s necessary to write code yourself for everything other than displaying the XML in the browser. And when you add features important to enterprise applications, such as security, reliability, and transactions, you also have to figure out how to write the code for that. The code could get pretty complex pretty quickly.
Now the next part of the discussion normally revolves around development tools, since they are pretty important in the use of SOAP (and WSDL for that matter). The basic question here is whether tools like XMLSpy, Visual Studio, WebLogic Workshop, or Artix Developer make life easier or harder. According to Jeff Webb, SOAP is harder if you want to change the auto-generated VB classes. If you just want to use the SOAP request unmodified, and take advantage of the generated code, however, then that is probably the simplest and most straightforward way to handle your XML.
And there’s the question of WSDL, which REST requests don’t have. Publishing a WSDL file on the Web ensures that your Web service becomes part of a larger “eco-system” since most Web services toolkits can import WSDL and automatically generate not only the SOAP message, but usually also the proxies and stubs to process it. Many tools are also available to generate WSDLs out of existing application metadata, including CORBA IDL, COBOL Copybooks, C++ and Java classes, EJBs, and COM objects, to name a few.
If you are already developing applications using an IDE such as Visual Studio or Eclipse, Web services support is already built in. And as more of the WS-* specifications gain adoption, they are added to the tools. For example, IONA’s Artix already supports WS-Security and automatically generates the SOAP headers for it. I think the principle about as simple as possible but no simpler definitely applies, and the reverse is true too. As complex as necessary but no more.
I think as the Web evolves “beyond the browser” it naturally encounters more complexity as it hits enterprise applications. It would be ideal if everything could be accomplished using simple HTTP interfaces and URL parameters. But the IT world beyond the Web needs reliability guarantees and transactional integrity for legal and business reasons such as ensuring the order of stock trades are carried out in the order the messages were received and verifying the identity of someone who sends a large purchase order for tons of steel. And the IT world is not going to change – not for a long time. The Web needs to adapt to the IT world, it’s as simple as that, to incorporate some of the complexity already there.
Ok – so let’s have some comments, and a good discussion!