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.
Related
There are actually two sub questions:
what's the difference between PHP curl library and libcurl? is the PHP curl library just a bridge to connect and use the libcurl or it is libcurl re-written in PHP language?
Why curl is much faster than the file_get_contents function in PHP?
the difference between PHP curl library and libcurl
PHP/CURL is a "binding" for the underlying libcurl library. It means that there's a bunch of glue code in the PHP curl extension that ultimately calls libcurl to actually perform the transfer operations.
The PHP code doesn't do very much more than converting from PHP conventions to libcurl conventions (and back again). It allows PHP users to take advantage of libcurl's raw native speed and latest developments without anyone having to change anything.
Why is curl faster than file_get_contents function in PHP?
Both are implemented in C and offer file transfer capabilities for PHP programs. The explanation is probably because of their respective software architectures and particular feature sets that makes one faster than the other for certain use cases.
There have possibly also been more work and efforts spent on optimizing transfer performance in libcurl.
As in most cases, it might be worth benchmarking exactly your case so that you know that you're not relying on speed tests done for cases that have other characteristics than yours.
i need to caching xml and json response requested to a remote host. Is There a simple Cache System developed in PHP?
If you are looking to get up and running right away, you can use APC, which is installed (or can be easily installed) with PHP, depending on what platform you are running PHP on. Then you can use the apc_add() function call to add keys into the cache.
Example:
<?php
$bar = 'BAR';
apc_add('foo', $bar);
?>
You can then use apc_exists() and apc_fetch() to check and fetch items out of the cache.
Obviously if your requirements are more complex, you may want to take a look at Memcached
PHP itself can't cache because it is interpreted at request time - there isn't any in-memory caching capabilities naively available. If you have control over the web server, you may be able to install APC cache. see this for a little info on how to use API. If not, you can check if that extension is installed (in my experience, not may hosts have this installed), ask for it to be installed, or simply grow your own (see below).
APC cache is a simple file-based caching mechanism that provides some neat facilities to expunge caches that grow old. You can build this yourself using the standard PHP library if APC isn't available (or you're doing something really simple). If you have to roll your own, use the above like as an implementation guide - build in the features you need and leave out what you don't. =)
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.
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.
I've looked online for ways to do this, and I've found two PHP methods for accesing WebDAV:
http://freshmeat.net/projects/class_webdav_client/
This is less than ideal, because it doesn't support WebDAV at a sub-path of the server; it cannot access, say, http://my-dav-server/configuration, only http://my-dav-server
http://php-webdav.pureftpd.org/project/php-webdav
This requires me to compile a new PHP module, which might be necessary, but is a bit of a pain. Plus, it's not clear from the docs how to do simple things like report errors or which versions of PHP it supports.
Basically, I want a WebDAV API - doesn't matter how complex, really - that can get/put files with HTTP BASIC authentication. I don't need anything more complex than that. I'm backing this with a subversion autoversioning DAV server, but I can foresee using it in other ways, too, so I don't want to lock myself in to subversion by using an SVN-specific API.
If you are just looking for GET and PUT, just use Curl! That, or any other decent HTTP library.
It's actually quite simple that way.