Difference between SoapClient request and Soap curl request in php

Question

I am very confused with

Soap curl request I found here an example SOAP request in PHP with CURL

and Soap request using SoapClient PHP

Answer 1

I have spent countless hours dealing with SOAP in PHP. Now I can claim that I know it inside out. :)

First question: SoapClient and cURL are intended for different purpose. SoapClient is all about SOAP, cURL is all about HTTP transport. SOAP being access protocol is one level up over transport protocol. SOAP may be transmitted by any transport you choose: often SOAP document (which is just plain XML document) is sent by SMTP (ie by email) in order to traverse through restrictive firewalls. cURL is just a tool to access some web server somewhere.

Second question: Speedwise time spent on local execution will be minimal in cURL. But this will be countered by low quality of such code as it will not follow SOAP standard and it is bound to fail one way or another (and it may not even let you know about it). Generally in execution most of time will be spent on transport (ie over slow network/busy web server) so it would not matter much which way you will use.

Now let's see under the hood: Soap extension in PHP is quite incomplete. Quick search for word "bogus" yields 33 different locations in the code. Most of them php_encoding.c . Unfortunately PHP SOAP in some cases just unable to produce correct SOAP or unable to understand correct SOAP - interoperability is a problem. Most issues are between PHP and .NET SOAP but I guess if you will try to access .NET SOAP with cURL you will need a bit more than just a few lines of code to get it going. Luckily plain SOAP is quite good in PHP SOAP and works with other SOAP implementations. If you want to use SoapHeaders or mustUnderstand be prepared to have a bit of a nightmare. SoapHeaders are relatively easy to do with cURL. mustUnderstand will be quite hard to do in cURL.

Main benefit of using SoapClient is WSDL (Web Service Description Language). Basically you can do:

$client = new SoapClient("http://webserver.com/service.wsdl");
$client->executeRemoteFunction($paramters);

With cURL you will be unable to do it because it does not have WSDL parser. If remote end will change its specs cURL implementation will fail miserably and will not let you know. At this point you can say: but if remote web server will silently drop executeRemoteFunction() then I would not know either! That's not the case: SoapClient with throw SoapFault exception and you need to catch it and handle it or your script will stop with unhandled exception message. Either way you will know about it.

However do not expect PHP SOAP to do some good stuff for you such as type checking. Even if remote WSDL would require xs:integer PHP SOAP would ignore it and will send whatever type you would provide silently. Type checking with cURL? Cannot be done because there no WSDL support in the first place.

Also while speaking about SOAP WSDL please be aware that PHP will cache WSDLs for 7 days (default setting). Rapid WSDL changes during development will get you in trouble in no time: clearing WSDL cache is not always easy. But on other hand you can disable WSDL cache completely during development: speed will go down but at least you will be able to develop without having "I have no idea why it does not do what I want!"

So reading about few good things in PHP SOAP you may wonder if there any good reason to use cURL for SOAP. And my answer is 'yes', there is. Unfortunately PHP SOAP is unable to create certain types of SoapHeader . So if you go to such advanced stuff you will need to use SoapClient to create SOAP document, then modify it with some XML tools (such as PHP DOM) and then send it off with cURL. But that's totally another story.

If you just start with SOAP in PHP do yourself a favor and stick with PHP SOAP extension, not cURL. It is cleaner way to deal with SOAP, it is fast, extension is maintained (so expect its interoperability to go up eventually), it understands WSDL and provides good error reporting and handling.