I know I’ve already mentioned it, but man I wish Google had a REST-style API. The new Yahoo web services are nice, and I’ve already been enjoying Amazon’s web services.
But, speaking of SOAP: For the sake of sanity, I’ve mostly been keeping my brain out of the tumult surrounding SOAP and WS-Tech. I was tracking things a few years ago, but have since wandered away.
I think I really need to dip into it again, though, because I catch myself regarding this behemoth of technologies as stupid and worthless–a reaction which I’ve been coming to consider as a red flag on my own ignorance, especially when there are a lot of smart people still seeing value in the same thing.
Part of it, I suspect, is that I tend not to use rich IDE’s on a daily basis, and I’m perfectly happy dealing with REST-style APIs using XPath to extract data and using DOM or string templates to send data. It seems so easy to me that I wonder just what I’m missing.
I’ve heard that SOAP and friends brings a lot of joy to people who can just drag-and-drop a schema or self-describing blob into their favorite tool and have all the webbish bits hidden behind native-looking calls and code. But, for the most part, I just don’t get it.
I don’t like working with Microsoft technologies much. However, it is what we use at work, between legacy ASP 3.0 pages and a smattering of .NET stuff we’ve been gradually phasing in.
One thing I do have to admit is satisfying, though, is using Windows Scripting Host with JScript to pry data out of Word documents and MSSQL tables to build a pile of XML documents–mostly because I didn’t think it would work.
-
About Me
Hi there! My name is Leslie Michael Orchard. I'm a serially enthusiastic, caffeine-dependent {web,mad,computer} scientist and {tech,scifi} writer working for the Mozilla Corporation and living near Ann Arbor / Detroit in Michigan.
-
Buy my books
8 Comments
Sometimes I wonder if it’s just the hacker mentality or instant gratification, but whenever I dig into SOAP, I get bored with it and want to move on. When I dig into a RESTful API like Yahoo! has, it’s so darn quick and easy to kick out an idea that it gets done before I ever get a chance to be bored with it. In fact, I get done, and am still excited about it!
SOAP by Example: http://www.intertwingly.net/stories/2002/12/20/sbe.html
Re: Google’s SOAP API vs a REST implementation, you might be interested in the XooMLe project, which is just that: a REST wrapper for the original API.
http://www.dentedreality.com.au/xoomle/
HTH, Cheers.
Manual trackback, re: working with Windows
http://therealadam.com/weblog/archives/2005/03/09/a-unix-expat-in-a-strange-land-of-windows/
I’ve never used REST, but I’ve lost all interest in the WS-* menagerie. This is a case of a standards body with a solution looking for a problem. IMHO, standards bodies are perfectly horrible sources of innovation.
First; build a prototype of a widget that solves a problem. Open source the widget. If the community decides the widget is good, then look to standardize the solution to the problem. The most importatnt part is the of software darwinism that is exerted by the developer community.
Les, what you’re missing about using REST is that tools vendors can’t target you. Hence no marketing and no IDEs. And, arguably, no advancement. Hey, one thing you -can- say about SOAP is that they just. keep. making. more. specs.
I don’t use SOAP much myself, but Macromedia embedded it pretty deeply into Coldfusion MX. The result is that SOAP services are ridiculously easy to deploy, because they’re built the same way you build everything else in CF.
For example, this is a local object definition with a single method:
<cfcomponent>
<cffunction name=”doFoo” access=”private”>
<cfargument name=”bar” type=”string” />
<cfreturn arguments.bar />
</cffunction>
</cfcomponent>
This is the same object, exposed as a SOAP service:
<cfcomponent>
<cffunction name=”doFoo” access=”remote”>
<cfargument name=”bar” type=”string” />
<cfreturn arguments.bar />
</cffunction>
</cfcomponent>
All that changes is the value of @access. No fiddling with the DOM required… the developer doesn’t even have to think about XML, since it’s all handled for her.
But then, if really bright people like Norm Walsh (”Mr. Docbook”) have trouble with WS-* (see his current blog thread on building a service) maybe there’s something to the theory that they are as broken as they look :-) I’m certainly regretting a project choice to use SOAP about 2 years ago; the APIs that are actually getting used now are HTTP (not-even-REST) shims that make the SOAP calls underneath, but http support works and is efficient in every language that anyone actually uses, which isn’t true of SOAP… I’m currently agitating for turning the stack inside out, and making the SOAP shims run on top of HTTP interfaces… and then give up on the SOAP parts if it turns out that they really get no developer traction. (Groove gets some blame for the SOAP hype, but it doesn’t seem to have resulted in any actual code for this app…)