Why I'd pick SOAP over XML-RPC
The raging debate of the week has been interesting to catch up on after being ill for a couple of days. The Google API has spawned an interesting thread between many parties over the API itself, SOAP versus XML-RPC and quite a bit of fringe discussion.
My simplistic take on things.
Google already had an API that they made available to partners, but it was probably more complex than it needed to be. They decided to implement a new API over SOAP. By making the API freely available with limits that impact its use in a commercial setting, they have gotten a lot of load testing and SOAP interop testing that would have been difficult for them to do on their own. A win-win proposition, which let's people use free tools to get acquainted, and enter a contractual situation if they need more from the Google service.
Edd Dumbill was correct to point out that other, more traditional screen scraping techniques exist, and are being used all over the place for things like this. But that's besides the point. Exposing functionality via SOAP (or even XML-RPC) separates the data and functionality from the presentation (or display), eliminating all the nasty work to figure out ever shifting screen formats. For companies providing services, it also allows them to set up a way to monetize the service if this should be a goal (this can been seen as good or bad, mostly depending on which side of the service you are on).
Another positive reason for exposing functionality via SOAP is the growing support for DTD's and WSDL (and potentially UDDI, that potential has certainly not been realized yet). I really dislike WSDL, but it's becoming a strong component of SOAP services (with automatic generation of interfaces now happening for many languages, including AppleScript). Feed the WSDL file to a generator and all the interface code is automatically generated.
This contrasts to the situation in XML-RPC land, where most of the connections are wired up by hand and DTD's (if they exist) may be out of sync with current implementations without repercussion.
I see this as being similar to the fight in the AppleEvent (AE) world in the early 90's. UserLand created the idea of Frontier glue files which could be shipped with your application to allow Frontier users to call all of your applications AE functionality. Eventually, Apple created the AppleEvent terminology extension, a convoluted resource description of AE functionality (much like WSDL in many respects). It took a while to pester people to add the ability to Frontier to read the 'aete' resource and generated stubs automatically. Hand wired interfaces versus automatically generated interfaces. There are things about XML-RPC I prefer (avoidance of the namespace issues), but I am going to have to use SOAP for anything I want to massively deploy.
11:51:31 PM 
|
