it goes against my stereotyped notion of a lisp developer that they would be interested in SOAP (contra-REST), and an interest in WSDL on top of that seems even more against the grain. Do you have any arguments for these technologies from a Lisp perspective that I might not have heard from the big companies?

While you link to the SOAP 1.2 spec, our current version implements SOAP 1.1. The 1.2 support will come in a few months. The docs are here for our interface.

bryan: going against the grain is not allowing people access to SOAP in Lisp. Also, if you look at the examples in the doc above, it is pretty natural in Lisp.

While WSDL and SOAP might not actually make me bounce around in joy, there are in fact a lot of "web services" deployed using those, and being able to easily access such can't be a bad thing.

It's entirely possible to use SOAP in a RESTy fashion. "REST is an architectural style -- not a dictation of protocol syntax" -roy fielding

The Atom API's SOAP bindings serve as a good example of how to use SOAP in a RESTy fashion, we specify the HTTP Verb in the SOAPAction header, the URI is still the URI,
what you would normally see in the HTTP Headers goes into the SOAP:Header and what you would expect in the HTTP Body goes into the SOAP:Body (we're talking document/literal SOAP and not rpc/encoded).

Easy as pie. And I don't have to worry that my HTTP libs don't support DELETE, etc.

'While WSDL and SOAP might not actually make me bounce around in joy, there are in fact a lot of "web services" deployed using those, and being able to easily access such can't be a bad thing.'

The only service that I can initially think of that is essential is google's. And that's growing less essential by the day (as search services go).
REST style services do seem to outweigh SOAP ones by a great deal.

'The Atom API's SOAP bindings serve as a good example of how to use SOAP in a RESTy fashion,...
what you would normally see in the HTTP Headers goes into the SOAP:Header and what you would expect in the HTTP Body goes into the SOAP:Body '

This seems to me to break some aspects of the REST style. The REST philosophy, while putting great emphasis on resources specified by uri's does also put emphasis on using http methods, to say that you're using http headers in soap headers just doesn't seem sensible to me. If they are no longer in the http header, then they are no longer a http header as I understand it. Is there some way with the newer SOAP specification to define that your SOAP header will bubble up to the http header if the transport protocol is actual http? (saying that sounds sort of stupid, but I can actually see a benefit to it), I know with the newer version of WSDL it is possible to do full REST services but what you describe does not sound like it.

I know like I sound like a militant anti-soapist here, but where I'm coming from is this, I was a fervent early adopter of SOAP, and I got burned by it.
And as the years have gone by and more things have been piled on top in the worst of worse is better fashion I have grown really to hate those letters.
That said I was recently at a web services implementors meeting, and one of the case studies actually convinced me that there is a scenario in which SOAP is correct, that is as an Enterprise protocol. The backend had SOAP running all over the place, and was actually able to take advantage of the protocol agnosticism.

Of course the web accessible service was also SOAP, providing static data that before people would have had to scrape from their web page, the amusing thing was that in their talk they admitted that they never could get their service to work with more than half of the SOAP clients out there.