We are investigating options to build a SOAP webservice in PHP. We have some requirements:
Authentication via SOAP Headers
HTTPS
Fine control over XML used in SOAP response
Good documentation and support community.
(Optional) WS Security support
There's the following tools providing such functionality:
Native PHP SoapServer
Zend_Soap
NuSoap
WSO2 WSF/PHP
PEAR::SOAP
Zend_Soap is actually a framework-compatible wrapper for the native PHP Soap-implementation. We have some simple tests running, but SOAP headers are not supported, and we don't have full control over the XML response. For instance, the response XML has a namespace on the root element, but not on it's child elements. Pretty annoying.
NuSoap is not really maintained anymore and I have read it has some issues with PHP 5.3 naming conventions.
WSO2 WSF/PHP uses a php extension which has to be compiled manually. There are some dependencies and the entire compile process is not clearly documented. The documentation is scattered around the website (sometimes outdated) and in the packaged downloads. A linux binary is mentioned, but nowhere provided for download (at least not in the last 5/6 releases).
I don't really know a lot about PEAR::SOAP, but I have some experience with PEAR classes. Usually they are not well-documented and do not catch errors gracefully, leaving you googling every error message, with varying outcomes.
Do you know of any other tools that can help me build a full-fledged SOAP server in PHP, considering our requirements?
If you need WS-Security, then WSO2 might be your only option. Did you install all the prerequisite packages (openssl, libxml2) before compiling. Compilation is simple with ./configure, make && make install (I didn't have any issues with 2.1.0 wrt. compiling). WSO2 offers full control of the payload XML structure.
If you can live without WS-Security, then any of the other options are good. I'd recommend PHP's own SOAP library. It's pretty decent, but doesn't offer very good control over the XML and lacks WSDL autogeneration.
I do not know any other. I used in the past always PEAR SOAP, but unfortunately it seems it is not maintained anymore. There you do not need a documentation, it is pretty easy to use.
But I would go the Zend-SOAP way if I had to build another SOAP client/server, because all others are not up-to-date.
Related
I am wondering the features that are fully supported within PHP Soap, I have tried researching this, but there is very little documentation to support PHP Soap.
Also how is Soap used during the exchange of data through client machine to web service then server.
I know this is fairly vague, but as I am constantly being asked this myself I thought it was better to find more about it.
PHP has some build in SOAP classes for both client and server. Docs is on here.
But you have to be sure that your PHP build is compilled with SOAP support.
"The features that are fully supported within PHP" are pretty much non-existent.
Built in SOAP client is ok only for basic services. It doesn't support any WS extensions, so you have to add support manually, e.g. including headers for WS-Security.
Also, there are some problems with namespace handling and creating requests.
If you'll be using it and are having trouble with missing parameters or badly formatted requests, you'll probably want to modify requests - this can be done by extending SoapClient class and overriding doRequest function.
There is a piece of software in my company connecting periodically with some webservices via SOAP protocol using curl in PHP. From time to time this fails and the whole system is very unstable. I was a bit surprised seeing curl as a main tool talking to these webservices, because I thought there exist robust and mature high level libraries for most languages (including PHP and python) and curl is relatively low-level and doesn't provide any error handling. Am I right? What is the best solution for communication via SOAP? Is there some enterprise standard I can follow? Please help.
PHPs build in SOAP Client is already very robust and abstracts many of the commonly needed stuff:
$this->soapClient = new SoapClient($wsdl_url);
// What interface is available, which function can you call?
var_dump($this->soapClient->__getFunctions());
// Call
$result = $this->soapClient->someMethodExposedByTheApi();
// Soap Elements (Tags in the XML) are available as properties:
echo $result->someProperty;
// Nested Tags are available as object chain:
echo $result->someNestedTags->nestedTag;
I could not imagine how it can be any simpler ...
If you need to setup a SOAP Service, you may want to use Zend_Soap, a stand alone component in the Zend Framework, that automatically builds a webservice based on a wsdl. It also has a wrapper on top of PHP's SoapClient, but this is mainly used to converge naming and coding conventions to the Zend Framework and does not provide much additional functionality.
However: Curl is ok if you have very specific requierements. If it fails from time to time and your system is unstable, than it's not a problem of curl. It may be a misconfiguration of the service or system.
Basically the SoapClient builds an XML based on the Standard. If you build the XML for yourself (for whatever reason), curl is ok.
If I want to create a web service or consume a web service that is defined as WSDL 2.0, what options do I have in PHP?
As I understand it the in-built SOAP libs in 5.x don't currently support WSDL 2.0 spec, and I can't see future support for this.
One of my former colleagues used to devour SOAP services manually, simply because he disliked the current .net implementation.
The SOAP implementation is based around you posting XML across the web to the service, and you "just" need to build a such XML and parse the results coming back. It is not as simple as it sounds, but it definitely is possible.
The WSDL2PHP project seems very interesting, and im very sure this can lead you in the right direction.
It's evident that the cURL functions are very widely used. But why is that? Is it really only because the extension is mostly enabled per default?
While I can certainly relate to not introducing 3rd party libraries over builtins (DOMDocument vs phpQuery), using curl appears somewhat odd to me. There are heaps of HTTP libraries like Zend_Http or PEAR Http_Request. And despite my disdain for needless object-oriented interfaces, the pull-parameter-procedural API of curl strikes me as less legible in comparison.
There is of course a reason for that. But I'm wondering if most PHP developers realize what else libcurl can actually be used for, and that it's not just a HTTP library?
Do you have examples or actual code which utilizes cURL for <any other things> it was made for?
Or if you just use it for HTTP, what are the reasons. Why are real PHP HTTP libraries seemingly avoided nowadays?
I think this would be related to why do people use the mysql functions instead of mysqli (more object oriented interface) or take a step further and use a data abstraction layer or PDOs.
HTTP_Request2 says that there is a cURL adapter available to wrap around PHP's cURL functions.
Personally a lot of the PEAR extensions I have tried out, I haven't been that impressed with (and I feel less confident with PEAR libraries that are sitting in alpha that haven't been updated in a long time). Whereas the HTTP_Request2 Library does look quite nice
I for one would have used cURL without thinking of looking at a possible PEAR library to use. So thanks for raising my awareness.
The libraries you mentioned aren't default, and from my experience in PHP, I prefer to use less of such libraries; they enable a broader attack surface, decrease reliability, open to future modification/deprecation more than PHP itself.
Then, there's the sockets functionality which, although I've used some times, I prefer to rely on a higher level approach whenever possible.
What have I used CURL for?
As some may know, I'm currently working on a PHP framework. The communication core extension (appropriately called "connect") makes use of CURL as it's base.
I've used it widely, from extracting favicons form websites (together with parser utilities and stuff) to standard API calls over HTTP as well as the FTP layer when PHP's FTP is disabled (through stream wrappers) - and we all know native PHP FTP ain't that reliable.
Functional reasons as mentioned in the comments:
It's very old, [widely used and] well tested code, works reliably
is usually enabled by default
allows very fine grained control over the details of the request.
This might need expanding. By nature of the common-denominator protocol API cURL might provide features that plain HTTP libraries in PHP can't...
Historic reasons:
curl used to be the only thing that could handle cookies, POST, file uploads...
A lot of curl use probably comes from tutorials that pre-date PHP 5.
I have a need to do RAW POST (PUT a $var) requests to a server, and accept the results from that page as a string. Also need to add custom HTTP header information (like x-example-info: 2342342)
I have two ways of doing it
Curl (http://us.php.net/manual/en/book.curl.php)
PHP HTTP using the HTTPRequest (http://us.php.net/manual/en/book.http.php)
What are the differences between the two? what's more lean? faster? Both seem pretty much the same to me...
Curl is bundled with PHP, HTTPRequest is a separate PECL extension.
As such, it's much more likely that CURL will be installed on your target platform, which is pretty much the deciding factor for most projects. I'd only consider using HTTPRequest if you plan to only ever install your software on servers you personally have the ability to install PECL extensions on; if your clients will be doing their own installations, installing PECL extensions is usually out of the question.
This page seems to suggest that HTTPRequest uses CURL under the hood anyway. Sounds like it might offer a slightly more elegant interface to curl_multi_*(), though.
HTTPRequest (and the PECL extension) is built on libcurl.
http://us.php.net/manual/en/http.requirements.php
The HTTPRequest is really just an easier/more syntactically friendly way to perform the same task.
As Frank Farmer mentioned, you're more likely to have a target platform with curl already installed and could have difficulty getting the PECL library installed by the hosting provider.
The HTTPRequest is "kind of" a wrapper for curl. This two quotes from the manual should give you a clue:
It provides powerful request functionality, if built with CURL support. Parallel requests are available for PHP 5 and greater.
The extension must be built with ยป libcurl support to enable request functionality (--with-http-curl-requests). A library version equal or greater to v7.12.3 is required.
Said that (and said that I've never used this extension myself), looks like if you want your code to look more object oriented, you can go for this one, but it might be a bit slower, though nothing compared with the external call that you are going to make, so I won't consider performance to make my choice. I would give preference to the fact that curl is built in and this other you have to add it yourself, which is unconvenient and reduces portability in case you want to host your app in a shared environment that you don't control.
For the needs that you explained in your question, I would definitely go for curl.