I’m wondering what pitfalls (if any?) developers here have run into when distributing WordPress plugins via the WordPress plugin repository that embed a SOAP client for accessing SOAP web services for critical plugin features (or any plugin distributed widely via any other repository, for that matter.)
(It is my assumption that a company publishing plugins would be much better off to develop RESTful web services but I am wanting to validate this opinion by surveying the opinions of others here. Note that I asked our very own @EAMann a related question on Namesake.com.)
I’m making this a community wiki so we can capture all thoughts on the subject.
I can’t speak to SOAP specifically, but I did build a plugin (private) for a client once that had to communicate with a proprietary third-party web service. In this case, it was a non-RESTful interface which used a mix of querystrings and XML POST requests for submitting queries (depending on the complexity of the type of query), and returned result data in XML.
I built PHP classes to help abstract out their service into an API I could deal with more easily, and to smooth out the inconsistencies in their interface and the different types of XML documents they accepted and returned. Also, by creating my own abstraction, I hoped to safeguard my code against future changes on their end. If they kept the same basic structure for organizing data, but switched to a JSON encoding, for example, most of my business logic would remain intact, and I would only need to rewrite my request and response pieces for encoding/decoding the data.
While not specific to your question, my past experiences with SOAP have been mostly negative. There has been a long-standing battle over whether SOAP is an RPC service, or a document transport. Couple that with complications arising from slightly non-standard implementations (search for articles about using perl’s SOAP::Lite module with a Microsoft SOAP server, for example), using XML namespaces, and other factors, and you will get frustrated pretty quickly.
I wonder, though, if your question is more specifically along the lines of someone building both the client and server-side SOAP pieces? If I was building a web service (and associated WordPress plugin to access it), SOAP would definitely not be my first choice for the API RPC or data transport.
I personally think connecting to SOAP can be a pain, especially if the server is Java, but I did do it in a custom plugin I developed for a client. Depending on your requirements you may not have to embed a special SOAP client since WordPress 3.2 dropped support for PHP 4 and PHP 5 has a built in SOAP client (search for SoapClient on php.net) Just make sure you make it clear in the documentation that it requires PHP 5. If you would like to support older versions of PHP that’s fine, but the only pitfall I see is conflicts with your library name.
For instance I want to use two plugins, one is a URL shortener and one is a twitter plugin. Well, the shortener plugin also has some twitter functionality and they both include the same OAuth library. Needless to say I’m getting errors now about redefining specific OAuth classes.
The way around this eventually will be PHP namespaces, but since we’re talking about supporting PHP 4 that’s not going to work. Your best bet will be to either rename the classes so that the library SoapClient for example is now MyPlugin_SoapClient and use that everywhere, or you might just want to wrap your include statements with:
And that will hopefully solve any conflict problems.