I develop custom WordPress plugins for my clients that they then distribute via the WordPress plugin repository. I'm increasingly running into clients who want my WordPress plugins to consume SOAP web services developed by their internal development teams (and as an aside, thus far every one of these SOAP web services have been developed using ASP.NET).

From my experience, especially within the realm of WordPress plugin development, interacting with RESTful web services is almost always trivial, and they just work. From my admittedly third-hand knowledge of actually consuming SOAP web services via WordPress plugins, especially ones that are widely distributed to mostly non-technical WordPress users, embedding a SOAP client is fraught with peril as there are so many things that can cause a SOAP web service call to fail; wrong local SOAP stack, missing local SOAP stack, malformed service response, etc. etc.

What I am finding is that many of the business people in decision-making positions within my (prospective) clients have little-to-no knowledge of the tangible differences between RESTful web services and SOAP-based web services. To these people a web service is a web service; it's 6 of one, 1/2 dozen of the other. They tend to think "What's with all the fuss?"

Further the ASP.NET developers at these client, developers who have been immersed in the Visual Studio toolset have been conditioned by Microsoft's excellent developer tools marketing to see SOAP as the easy way; just add Visual Studio and the SOAP web service works like magic! And it does, at least until you try to use some other stack to access the web service and/or until you are trying to get people who are not using Visual Studio or adopt the web service; then the picture is very different.

When these developers hear me advocate they implement a RESTful web service instead if I get push back I am getting one of two responses; they say:

  1. "Why go to all the effort of creating a RESTful web service when I've already created a SOAP web service for you to use? You are just creating more work for me and I have other things to do."

  2. "There is no benefit to RESTful web services; SOAP is actually much better because I can create an object and then I can program it just like an object. Plus SOAP is used by enterprise developers and we are an enterprise development shop; REST is just not for serious use."

As an aside I think one reason I get these responses is because ASP.NET developers often have little-to-no exposure to REST (isn't this article really on the fringe for most ASP.NET developers?) I think they really don't know how little work it takes to create an HTTP GET-only RESTful web service once they already have all the code implemented for a SOAP web service.

And I think this happens because Microsoft's approach is to give tools to developers so they don't feel the need to learn the details. Since Visual Studio claims to take care of so many things for developers why should a developer care to learn anything that Visual Studio claims to handle? I know that's what I thought when I used to code web sites for the Microsoft platform. It wasn't until I moved to PHP that I realized what HTTP headers were and that I realized the difference between a 301 and a 302 HTTP status code, and most importantly that I realized these concepts were both easy to understand and vitally important to understand if one wants to create a robust and effective site on the web.


What I am asking is how do I counter these responses and get my prospective clients to consider creating a RESTful web service? How can I get them to see the many benefits that using a RESTful web service can offer them? Also how can I get them to see the large potential downside of releasing a WordPress plugin that potentially incurs a large support cost?


If you disagree with my premise that calling RESTful web services are preferable to calling SOAP web services from within a WordPress plugin then please understand that I'm asking for help from people who agree with my premise and ideally I'm not looking to debate the premise.

However if you feel the need to argue then please do so in a respectful manner recognizing that we each have the right to our own opinions and that you might never be able to sway me to agree with yours. Which of course, should be okay.

  • 10
    If you do not know the answer to this question, why are you pushing RESTful services in the first place?
    – ozz
    Commented Apr 15, 2011 at 9:06
  • @james - Knowing the technical benefits of RESTful web services is not the same as knowing how to play politics with different players within a client organization and my question is about the latter. Commented Apr 15, 2011 at 11:24
  • @mike - ok - this question could be a lot shorter then, and you could have avoided the debate/cartoon stuff, why bother mentioning the tech at all? "How do I get past office politics?"
    – ozz
    Commented Apr 15, 2011 at 12:16
  • @mike - Your highlighted question is all about the tech - "What I am asking is how do I counter these responses and get my prospective clients to consider creating a RESTful web service? How can I get them to see the many benefits that using a RESTful web service can offer them? Also how can I get them to see the large potential downside of releasing a WordPress plugin that potentially incurs a large support cost?"
    – ozz
    Commented Apr 15, 2011 at 12:18
  • If you drop the back story your question basically boils down to this: programmers.stackexchange.com/questions/23386/…, does it not?
    – Steve
    Commented Apr 15, 2011 at 12:46

9 Answers 9


So while I tend to agree with your position, I'm still going to throw out some ideas for balance. First the issue:

"Why go to all the effort of creating a RESTful web service when I've already created a SOAP web service for you to use? You are just creating more work for me and I have other things to do."

The problem is that they've already done work. More than likely, based on your description, these web services are WCF services. Microsoft has really taken the pain out of creating SOAP based web services, so from a development/maintenance perspective it makes sense from the client's perspective just to use the WCF stack. If they had gone through the trouble of rolling the SOAP stack themselves, you wouldn't have such a hard sell.

The problem, as I see it, is that Wordpress (a PHP technology) is ill equipped to handle SOAP. SOAP is a "standard" non-standard adaptation of the HTTP protocol. In short, instead of your typical request and HTTP header information as part of a normal client, there is an XML body as well. That XML is usually mapped to objects and has its own header information. In short, it's not something that PHP is designed for out of the box. Are you using PHP:SOAP? Hopefully it makes using SOAP easier.

However, more on practical strategy later.

"There is no benefit to RESTful web services; SOAP is actually much better because I can create an object and then I can program it just like an object. Plus SOAP is used by enterprise developers and we are an enterprise development shop; REST is just not for serious use."

This is actually much easier to deal with. In short, most web services I've seen have very simple request models. All you need to pass in is an ID and some authentication token. That's the trivial type of interaction that RESTful web services thrive on. You can return an XML or JSON bound representation of your object quite easily. In fact, the MS stack has the binding logic for both of those. Very rarely does a client need to send complex hierarchical data to the server.

Practical ways to make both of you happy

I know it may sound silly, but have you considered a web service wrapper? Something that translates the REST calls you need to keep Wordpress happy into the SOAP based calls that makes your client's WCF services happy? That might be the most peaceful way of dealing with it. Having done RESTful web services using ASP.NET MVC, it would be trivial to keep things in the Microsoft stack where you need it, and perform the translation to the PHP stack in a sane manner.

  • 3
    +1 I would also add, that all the problems Mike pointed out are really problems with PHP, not SOAP/WS itself. Commented Apr 15, 2011 at 15:02
  • 2
    @Jacek Prucia - "Problems with PHP, not SOAP/WS itself" - Exactly. That was (should have been) implied by my first sentence which said I was writing plugins for WordPress. .NET to .NET SOAP works brilliantly, but that's not what I'm doing. Commented Apr 16, 2011 at 5:08
  • @Berin Loritsch - Thanks for the answer. I do not know the (current) Microsoft stack, hence the reason I asked the question. Is SOAP based on WCF? Your point about PHP and SOAP is bang on and why this is an issue. I wouldn't be asking this if I were developing for them in C#. And if I'm using PHP:SOAP, I asked this question in the rare case I do decide to try and implement against a SOAP service: wordpress.stackexchange.com/questions/14804/… That said, your "wrapper" idea sounds excellent, but... Commented Apr 16, 2011 at 5:13
  • ...Your wrapper ideas leaves me with two questions: 1.) Is this something that can easily be run side-by-side on their server or will it need more infrastructure on another service? Can this be offered up as a self-contained thing we give them and say "Here, install this?" 2.) Are you available on a freelance consulting basis to build this and/or future SOAP wrappers? (I'm asking seriously.) Commented Apr 16, 2011 at 5:16
  • 1
    I have almost never seen a SOAP message that only took an ID and some authentication token - Some of the requests I have had to make are kilobytes long and return megabytes of response. Commented Nov 23, 2016 at 0:51

Here's a thought for you: why don't you give the client what they ask for? They are, after all, your client and their first point is an extremely valid one. Why should they do extra work because of your second-hand qualms about SOAP services?

If you genuinely believe that this will increase your workload then make sure the type of service they provide is written into the contract and bid more where they specify SOAP.

Should you be proven right, rather than just a language-troll with a beef against Microsoft-stack devs, then you'll have a better argument next time than calling their developers (who they probably trust a lot more than they trust you) "fat, dumb and happy."

  • 2
    +1, the client is always right. It is good to point out potential pitfalls early on, such as "I've had really bad experiences using SOAP to do this" - but that's all you can do.
    – user131
    Commented Apr 15, 2011 at 7:21
  • 9
    @MikeSchinkel - If that's how you read my answer then it was a self-fulfilling prophecy. I never said you were wrong, I said that the client is entitled to be wrong and still get their own way. I did suggest that your argument is phrased in a way that comes off as one who is trying to start a fight, and your response here only backs that belief.
    – pdr
    Commented Apr 15, 2011 at 8:06
  • 3
    @MikeSchinkel - So now you're telling me that you reacted without even reading my answer. And yet I'm the troll. You'll forgive me if I leave you to your rantings.
    – pdr
    Commented Apr 15, 2011 at 9:24
  • 5
    @Mike: While I tend to dislike anti-answers such as this one, in this case the logic is totally sound. If you are "increasingly running into" people who want to do something, and are not only refusing to do it simply because you don't like it (as opposed to it actually being impossible or impractical), but actually also using it as a platform to evangelize, then (a) you're being a jerk, and (b) you are losing potential business, either directly or indirectly through goodwill. I've worked extensively, first-hand, with both SOAP and REST services and quite frankly think you're full of it.
    – Aaronaught
    Commented Apr 15, 2011 at 16:11
  • 3
    @jwenting - So you too are not able to be respectful as request in the question either? Sigh. When did I say I was always right? Sorry, but nowhere in there did I say anything that meant that. What I said meant that as a consultant I'm not required to accept projects that I believe are not in my either mine or the client's best interest, even if the client believes otherwise. "Customer is always right" is a "philosophy", not a "truism" as you and some others seem to believe. Commented Apr 18, 2011 at 9:08

My answer to you is that you can't. I don't know your clients, but from your description they do not sound as if they are ambivalent in their determination. They have asked you to provide a service, so I suggest you provide it or move on.

On a supplementary note, much of the body of your question involves accusations against Microsoft for creating lazy programmers. Is this your indictment of Microsoft question or is that relevant to the programmers who have made the decision to use SOAP? Are you calling them lazy or just taking potshots at a software company? I suspect this is less about the politics of getting them to use a "better" technology than it is about you forcing your comfort zone down their throat. My suggestion to you as a freelance developer (which is what I'm assuming here) is that you need to learn to adapt to client's requirements. Recommending alternative solutions is only appropriate if you can show a cost/benefit analysis that is tangible or if the client has no real knowledge of the process involved and is making uninformed decisions.

Other than that, it helps to follow the axiom: The customer is not always right, but the customer is the one paying the bills.

Note: I am not in any way saying you are right OR wrong. My comments are simply intended to point out what may be fuzzy thinking on your part with respect to how the client/provider relationship works. I am also attempting to get you to review your perceptions of the people/tools involved here, particularly with how you view things.

  • 1
    I will move on if I can't find a way to keep the WordPress plugins from having to access SOAP. But if I can get their management to understand why SOAP is problematic for this use case without alienating their programmers then I would like to. I'm not casting blame so much as describing the outcome. If there is any blame it is Microsoft's but I recognize Microsoft thinks it's in their best interest and they are far too profitable for me to argue that it is not. I'm not blaming the .NET programmers; I once programmed the Microsite-stack and I knew little about HTTP then. Commented Apr 16, 2011 at 5:21
  • There may be truth to "comfort zone" but regarding the supportability of SOAP within a widely distributed WordPress plugin, not about any lack of desire to learn. Frankly I'm one that always learns new things about WordPress (here's proof) and part of me wants to learn PHP+SOAP, but I don't want to make a mistake and end up with tens if not hundreds of support issues because of using SOAP where I shouldn't. And in these cases, there are not yet customers, they are prospects. No bills paid yet. :) Commented Apr 16, 2011 at 5:37
  • Also, if I'm right about the issues I might have with supporting SOAP, I'll be doing the "customer" a huge favor but guiding them to REST. Commented Apr 16, 2011 at 5:38
  • @MikeSchinkel: Not having done wordpress plug-ins I can't really provide any insight in that direction. If these points you raise are this impactful then it shouldn't be difficult to generate a cost/impact analysis for the management team. If you can clearly demonstrate that SOAP will be costing them time/money you shouldn't have any difficulty changing their minds on it. If they still don't then your choice might be made for you. Commented Apr 16, 2011 at 11:43
  • Here's the issue. Unless the cost/benefit ratio is something I can do and reuse, this issue is often coming up at the front-end before payment when the client has said they want to use me because of my WordPress plugin expertise and specialization but then they tell me they are building a SOAP web service for me to call and they've yet to commit to pay me anything. But thanks, I think by discussing this issue I'm getting what I need. Commented Apr 16, 2011 at 19:22

Convincing over the price the client has to pay to you

One has to pay the price of more effort/cost: Your client or you.

You can solve this problem through the price: Integrating soap-service is more expensive for the client than the integration of REST. This way the client has the choise.

  • 2
    You can also add that it will take much, much longer to have a SOAP web service capability that is fully working without errors. Commented Apr 18, 2011 at 8:30
  • @Christopher Mahan - Thank you for addressing the key concern. Commented Apr 18, 2011 at 9:33

You seem to have an awful lot of prejudice against Microsoft tied up in your dislike of SOAP. The early history of SOAP is from a Microsoft project, it's true. But you are aware, I hope, that it has been a W3C recommendation for nearly eight years now, and that the SOAP specification is currently maintained by the W3C's XML working group?

Actually, these days, I far more often encounter SOAP webservices from Java developers than .NET developers. But both Java and .NET developers tend to like it because it is cleanly and easily supported by pretty much every major platform. I'm honestly surprised that you're having such difficulties interacting with SOAP services in PHP, I have no real PHP experience but I really would have thought that it would support such a widespread and long-standardized protocol.

  • 1
    You misread my comments about Microsoft and SOAP. This question was not about SOAP vs. REST, it was about calling SOAP services not being a good idea from within a PHP-based WordPress plugin and the potential support fallout that would create, pure and simple. FYI, I implemented a basic SOAP parser in ASP+VBScript back before there were SOAP parsers. I've also followed many discussions over the years on rest-discuss about the pitfalls of SOAP. So I do know quite a bit about early SOAP history and REST too. Commented Apr 16, 2011 at 5:49
  • 1
    Yes there are several SOAP clients for PHP but the issue is that WordPress plugins get executed on many different shared web hosts and as far as I am concerned there is too much complexity in getting a SOAP stack working and then getting SOAP messages passing in so many places (potentially on thousands of disparate servers) that the chance of having a large number of support issues is just too great to risk. Also Java web services are really tangential to this question. Commented Apr 16, 2011 at 5:55
  • SOAP was invented by Don Box (possibly as a joke, or a bet to make DCOM work over the web), after it became popular was he hired by MS.
    – gbjbaanb
    Commented Aug 1, 2011 at 13:38
  • Also we've found that the SOAP web services produced by WCF are not 100% compatible with those produced by some java libraries. I don't know (or care) which endpoint is 'wrong', just that its not quite the universal standard that its made out to be.
    – gbjbaanb
    Commented Aug 1, 2011 at 13:39
  • It is NOT cleanly and easily supported by every platform, this Statement is simply not true. It may be for the very simple use cases, but I have seen trouble starting at "nillable" and not ending with WS-*. SOAP is s standardized nightmare, since nobody really implements the standard.
    – JensG
    Commented Oct 30, 2013 at 0:34

Presuming these developers are using newer .NET stuff, they should be using WCF. Then making the service run over REST vs. SOAP isn't hardly a challenge -- just switch the bindings and they are done. Same codebase can easily serve all sides.

From the PHP side, you might not be used to SOAP but I've worked successfully with SOAP in the past using nuSOAP. AFAIK, PHP 5+ have a SOAP stack baked in so it shouldn't be too hard to work with the stuff.

  • +1, thanks for the help. If I was doing it at one location I would not be concerned for supportability like I am. When you used nuSOAP client was your software deployed in one single controlled environment (i.e. on your servers or those of your clients/customers) or potentially over thousands of disparate shared web hosts over which you had no control? Commented Apr 16, 2011 at 6:04
  • nuSOAP, at least, was regular PHP files you could deploy with your stack without strange dependencies, at least it was the last time I used it. Commented Apr 18, 2011 at 1:25
  • Thanks for acknowledgement about nuSOAP. I've since found a WordPress plugin that uses it; I'll have to contact its author and see if he has experienced any support issues. Commented Apr 18, 2011 at 2:19

you're wrong, Mike. The client has a SOAP service in place, you'd better set aside your hatred of SOAP and work with it. If you want the job that is, you could always hand back the assignment and any money already paid to you (plus possible severance fees and penalties if stipulated in the contract) if you're too lazy, incompetent, or strung up to use anything you're not a fan of.

Instead of doing your job, you're telling the customer they have to do it for you.

  • 3
    Perhaps you could reword this to sound less like a flame-filled rant? Commented Apr 18, 2011 at 8:41
  • Trouble with reading comprehension, eh? Please read my copious other comments that explain how my issue is with SOAP in this context, not with SOAP in general. Incompetent? Maybe we should compare your StackExchange network contributions with mine before throwing stones? Commented Apr 18, 2011 at 9:31

Although I whole-heartedly agree with the other answers telling you that you've got a serious problem of perspective, I do have a practical solutions for addressing both points:

1) Why go to all the effort of creating a RESTful web service when I've already created a SOAP web service for you to use? You are just creating more work for me and I have other things to do.

Assuming that the SOAP services are built using WCF, it's actually no effort at all. All you need to do is slap on a webHttpBinding and a couple of attributes, and boom, you're done, it's REST. Or at least a close enough approximation of REST for this purpose.

2) There is no benefit to RESTful web services; SOAP is actually much better because I can create an object and then I can program it just like an object. Plus SOAP is used by enterprise developers and we are an enterprise development shop; REST is just not for serious use.

There may be no benefit of changing their architecture from SOAP to rest, but since WCF allows you to set up multiple bindings on the same service, they can simply run the REST (webHttpBinding) and SOAP services side-by-side. This has one immediate and very obvious benefit: it's cheaper for you to implement because you already support [JSON / POX / whatever]. If 20 minutes of work on their side will save them $1000 on your contract then I'm sure they'll see the advantage.

  • @Aaronaught - I do appreciate your help, thank you, but I don't understand why you are compelled to judge so quickly. You are judging from your perspective without appreciating mine, and from I read you still don't get why this is an issue (the issue is because I'm calling from a WordPress plugin where SOAP is just too big of a support risk.) I would vote up your answer because from a technical perspective you answered well, but I can't bring myself to vote up an answer that starts with a personal attack. Commented Apr 16, 2011 at 6:00
  • @Mike: If you feel that a correct answer is not worth an upvote because it includes one single statement telling you something that you don't want to hear, then it is entirely your prerogative not to upvote it. However, I'm not engaging in personal attacks, I'm simply stating facts; SOAP is not a support risk, your insistence otherwise based on second-hand information and no personal experience is unprofessional, and quite simply put, if many of your clients want the same simple thing then as a consultant you'd make more money with less stress by supporting it instead of arguiing with them.
    – Aaronaught
    Commented Apr 16, 2011 at 14:50
  • I would also posit that your gratuitous upvoting of identical answers, posted later but without caveats, is further evidence of this inappropriate stubbornness. Refusing to listen to practical advice because it doesn't agree with every one of your beliefs is not going to make your life or career easier in the long haul. Beyond that, I have nothing more to say on the issue.
    – Aaronaught
    Commented Apr 16, 2011 at 14:52
  • 1
    @Aaronaught - I see you continue with the attacks based on your apparent belief that you know the one answer to all scenarios. Your "SOAP is not a support risk" is patently unprovable (you can't prove a negative) and your asserting shows a level of immaturity. As far as "2nd hand information" I'm moderator on WordPress Answers with a top 3 rep, so give me a little credit here, and of 5000+ questions there has only been one question tagged [soap] besides the two I just asked, so people are simply not using SOAP with WordPress which tells me there something to this SOAP avoidance. Commented Apr 16, 2011 at 19:28
  • 1
    @Mike: I'm really not interested in arguing the point with you. If you want to make major decisions affecting both you and your clients based on circumstantial evidence and no firsthand knowledge, be my guest. Go ahead and downvote if you honestly consider that half-sentence to be "pious sermonizing" - I truly don't care. But please stop trying to convince me that there's a single shred of evidence supporting any of your biased claims, because you wouldn't have had to ask this question if there was. It's sad that you choose to react with such hostility toward people who genuinely try to help.
    – Aaronaught
    Commented Apr 16, 2011 at 20:00

Different programming languages tend to work better with one style of web service interface. For example, I know that Java is happier with SOAP in practice (there's lots of really good tooling for it these days) and a colleague of mine reports that Ruby's happier with REST. Moreover, some functionality is strongly restricted to either SOAP or REST; SOAP isn't tied to HTTP and has a lot more support for sophisticated security models, whereas REST is definitely better for large file transfer. (This is all a consequence of SOAP being message oriented whereas REST is more connection oriented.)

Given that there's actually no clear winner between SOAP and REST in all situations anyway, why are you seeking to force those who would pay you to make changes just to accommodate your prejudices? You don't know all the constraints that they're operating under. You don't know all the client software that they are making their services work with. Instead, you should investigate how to make your software more robust against the configuration problems you've identified (e.g., through changed packaging or reduced dependencies). It might even be enough for you to improve the documentation on how to install and use your code, or even for you to sell installation support.

  • "why are you seeking to force those who would pay you to make changes just to accommodate your prejudices?" - Primarily to eliminate the potential of complex, costly and hard to debug support issues that might arise from using a PHP SOAP client to call a Microsoft stack SOAP server in software that will be widely distributed and run on god-knows-what shared web host. "you should investigate how to make your software more robust against the configuration problems you've identified" - That's almost impossible given where the code will run; too many haystacks with needles. Commented Apr 18, 2011 at 9:15
  • It feels like you and others are preaching some form of morality but this is not a moral issue. I have the right to choose my clients just as they have the right to choose me, and I don't need business that might cause support headaches. I would like to serve these clients but I don't need these clients. What I do is specialized and there are few others available to do it. Why shouldn't I advocate for prospects to do what I truly believe is in their best interest? If they still want to go against my recommendations then they are a better client for someone else. Commented Apr 18, 2011 at 9:24
  • 1
    "If they still want to go against my recommendations" ... have you considered that they may just have different priorities than you?
    – JensG
    Commented Oct 30, 2013 at 0:36

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