6

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.

5
  • I am tempted to close this as "not a real question" or "too localized" since it's been up for a while and silence might be telling that this is fishing for answers that simply don't exist... Is using SOAP API essentially any different from any other API or similar network functionality?.. Agree/disagree?
    – Rarst
    Commented May 30, 2011 at 21:22
  • @Rarst - SOAP APIs and RESTful APIs are very different. SOAP is a very elaborate XML-based protocol that uses HTTP as a transport and is promoted by large vendors with complex tools to sell (see @Dougal's answer for more on the debates among SOAP devotees on what it is exactly), and REST is just HTTP with additional constraints. It's like the difference between an automobile engine and a jet engine. Both generate power but each do it very differently. Commented Jun 1, 2011 at 18:04
  • Naturally I know there is technical difference between protocols. However is there WP-specific difference between "my plugin has SOAP API wrapper soemwhere in the corner" and "my plugin has REST API wrapper somewhere in the corner" ? I feel that this is question about viability of SOAP in general, rather than viability of it in WordPress.
    – Rarst
    Commented Jun 1, 2011 at 19:06
  • @Rarst - WordPress plugins are distributed and will run on many different hosting environments so it's specific to widely distributed issues. It's also about if any SOAP stacks conflict with WordPress's core in any way. Commented Jun 1, 2011 at 20:37
  • It's network communication so won't it just go through HTTP API ? It's created exactly to abstract code from hosting specifics and compatibility issues.
    – Rarst
    Commented Jun 1, 2011 at 20:40

2 Answers 2

3

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.

1
  • Thanks for your comments. I was asking about someone building only the PHP SOAP client to run in a WordPress plugin for someone else's .NET SOAP server. I can't even find an example plugin that does this. And your experience was what I am fearing. Commented Jun 1, 2011 at 17:59
3

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:

if (!class_exists('SoapClient')) { include 'inc/soapclient.php'; }

And that will hopefully solve any conflict problems.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.