Why I prefer SOAP so far… or XSLT+XHTML+WSDL+SOAP for discovering, inspecting and accessing Web Services.

I won’t claim to be the biggest expert in the REST vs SOAP debate… and I also know that I’m not the most experienced developer when it comes to web services and distributed systems.

But I’m not a total noob either.

I’ve had a fair amount of professional experience with XML-RPC and SOAP, and I’ve done my reading on REST. I find the dispute fascinating. I’m impressed with the simplicity and elegance of REST concepts even if I find claims that REST, by definition, embodies the original ‘intent’ or ’semantics’ of the Web, HTTP, or URIs often to be a bit of a stretch. I’m not a REST hater. In fact, I’d be happy for someone to respond to this post with counterpoints that show how these SOAP+WSDL-based concepts can be achieved with existing REST practices.

So here’s my big reason for preferring SOAP so far… automation and auto-discovery. It seems that one of the big complaints about RPC-style Web Services from the REST camp is that SOAP+WSDL is so complicated… even when the underlying interaction need not be. I can certainly see where this argument comes form. But… when it comes to WSDL… there’s gold in them there hills!

SOAP and WSDL may seem a bit ‘heavy’ for implementing very simple, non-transactional Web Services… but I would argue that the problem of added complexity for the service provider is far outweighed by the potential added value SOAP+WSDL provide to clients.

First of all, mature SOAP and WSDL tools are present in any modern programming language… thus easing the complexity of making requests for potential service consumers. But that’s not my point… using REST-style query string args are still much easier than using even the best SOAP library to create requests.

My point is that with a little ingenuity (and some of the technologies in this article’s title) WSDL (and possibly UDDI or a similar standard) can be used to create intelligent WS clients that can not only auto-discover services, but dynamically build user interfaces for those services. With additional spit and polish, slick, dynamic, WS client applications could be targeted at the general public. Think of Watson or Sherlock, but not with a static, pre-defined set of services or channels… but an unlimited number of services with new offerings constantly appearing.

The model is simple…

1. Transform WSDL to an XHTML user interface using XSLT.
2. Display XHTML interface in client app (web-based or more traditional desktop app with an embedded IE, Gecko or WebKit engine).
3. User manipulates interface to get desired information/access services.

And just for shits and giggles… here’s an example application of this idea…

Download Version 0.2 of SOAP Client my Cocoa app for accessing and debuggin SOAP-based Web Services.

Version 0.1 of SOAP Client had no WSDL-parsing capabilities. You had to manually find a SOAP web service, and then learn its endpiont URI, its methods, its method namespace and possibly its SOAPAction header. Additionally, you had to specify the correct method params using JavaScript syntax from scratch. If you forgot a param, or botched some other attribute, you’d likely get a ‘NoSuchMethod’-type error from the server.

With version 0.2 of SOAP Client, you still have to manually discover a WSDL file that describes a SOAP service… but v0.2 includes WSDL-parsing capabilities (that are admittedly largely untested… thus the low version number) that discover all of these attributes of a given SOAP web service automatically. All you have to do is point SOAP Client at a WSDL file… a dynamic XHTML user interface with all of the service’s methods will (read should) appear automatically.

SOAP Client (using XSLT) will provide you a list of the available methods as well as discover the endpoint URI, method namespaces and SOAPAction header automatically behind the scenes. Then, as you choose a specific available method, you are presented with an XHTML form UI for the necessary params for that method. What could be easier?

Some caveats: SOAP Client 0.2 is highly experimental, and has only been tested on a couple of collections of SOAP web servcies. Therefore, I am keeping version 0.1 available as well. Eventually, a combination of the two approaches into a single app might be nice for ultimate flexibility. For now, I haven’t the time. If you’re interested, dig in and see if either one meets your needs.

If you wanna get started with version 0.2, I’ve done testing with the services available from Google thru this WSDL file: http://api.google.com/GoogleSearch.wsdl and xmethods.net from this WSDL file: http://www.xmethods.net/interfaces/query.wsdl. The Google services require a unique authentication key that you’ll have to register for. The xmethods services, on the other hand are much more extensive, and do not require a key. If you wanna try SOAP Client 0.2 out, I suggest you download it and point it at the xmethods WSDL file above.

I said earlier that with some ’spit and polish’ a user-centric consumer application for browsing and accessing web services could eventually be created. Please note that I DO NOT consider SOAP Client to be such a app. It is still very developer-centric, and is not consumer friendly. But its a good first step on the road to a final concept. I hope you try it out and like it.

Update SOAP Client supports only WSDL 1.1. It does not currently support WSDL 2.0.