Tim Woodcock wrote:

"SOAP" and simple do not belong together in the same sentence.

If you want simple, XML is ok. But SOAP is a way of adding software context on top of data. That is not simplicity.

Yes, the SOAP on-the-wire protocols are complicated, especially when you start adding WSDL into it. It's not fast, either.


But - you don't have to look at the wire protocol to use it, because pretty much every combination of platform and language has a SOAP client library available. A reasonable library should make accessing a SOAP API simple - as an example, it's more than possible to write SOAP client one-liners with Perl and SOAP::Lite ... yes, you can leave the 'all Perl looks like a one liner' gags right there :)

Seriously though, this *is* simple:

  use SOAP::Lite;
  print SOAP::Lite
    -> uri('http://www.soaplite.com/Temperatures')
    -> proxy('http://services.soaplite.com/temper.cgi')
    -> f2c(32)
    -> result;

(from http://www.soaplite.com)

That's a trivial example though, and any OpenSRS SOAP API would necessarily have more elaborate methods than 'f2c', but as the library should take care of type conversions and so on, using the methods should be no less simple.

This isn't to say, however, that SOAP is the only way forward. All I'd like to see is simply OpenSRS accepting that what's needed is an API, not a set of client CGI scripts with a reasonable but underdocumented API buried underneath. Sure, the methods themselves are pretty well documented, but as far as I can see, the documentation for the transport is XML_Client.pm and friends.

Perhaps a reasonable first step would be to document the entire protocol in a language-neutral way, and then there'd be no excuse for those who don't speak Perl not to build a client for the current API with whatever system they choose.


Chris.




Reply via email to