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.
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.
So I'm about to implement stripe payments to one of our projects and I've read the documentation of their API which stands as:
The Stripe API is organized around REST. Our API is designed to have
predictable, resource-oriented URLs and to use HTTP response codes to
indicate API errors. We use built-in HTTP features, like HTTP
authentication and HTTP verbs, which can be understood by
off-the-shelf HTTP clients, and we support cross-origin resource
sharing to allow you to interact securely with our API from a
client-side web application (though you should remember that you
should never expose your secret API key in any public website's
client-side code). JSON will be returned in all responses from the
API, including errors (though if you're using API bindings, we will
convert the response to the appropriate language-specific object).
They have a good pack of ready-to-use API libraries for popular languages so you import them to your favorite language and just start using their API, including PHP, which is what we are using for this project.
Now, their API is large and they have a lot of objects. We are not actually going to use the whole set of features so my initial thought was to just wrap around their HTTP RESTFul interface around simple cURL code so I don't have to load their whole set of classes for the sake of performance.
Now, before I actually implemented my own cURL client arount their HTTP API I took a couple of minutes to look at the sources of their PHP libraries and they seem to do exactly that: wrap around cURL functions, throw errors, expose objectified responses, etc.
Then the question is: Is it worth to just use their library even when I know I'll be loading a lot of clases I won't use, or should I write my own wrapper with cURL around their REST API?
Consider that this question came to my mind sice we are using other services (TangoCard, for instance) and most of them have deprecated "native" libraries favoring the use of whatever is your favorite HTTP client library and just use the REST API.
Thanks!
Loading classes is almost a non-issue in terms of performance, especially if you are using APC. I think the time saved by using what they give you completely justifies the slight performance loss due to loading their classes.
However, if their code is well written you shouldn't load any classes you don't actually use.
Also, if they maintain their library it will be easier to receive updates as time goes on. For instance, we used to roll our own Facebook APIs that used curl and had to stop due to their high number of updates and breaking changes over time.
I would strongly recommend using the official libraries.
Stripe's official code has certainly been developed carefully and tested deeply. Especially for important things like handling payments and dealing with customers' money, I believe you should want the most stable platform possible.
The difference in performance, even without caching systems such as APC, should be totally negligible, and unless your scale is comparable to Amazon's or other big online stores, I hardly doubt you should focus your resources in optimizing that part of the code.
Additionally, using the official library makes it easy to maintain and update the code in response to changes on Stripe's side.
What frameworks/tools are there to help run javascript from PHP? Is there anything like the harmony project for PHP? I am hoping to perform JS unit tests (or even better, BDD) directly from PHP, inspired by this post (for Ruby). Am I asking for too much?
There is in fact the Spidermonkey PECL extension, which embeds THE mozilla Javascript interpreter in PHP. It will however not provide the document.whatever object tree that browsers have. So I'm not sure which kind of JS unit tests you could possibly accomplish with this.
Maybe you can utilize env.js and co like that Ruby project does. But I'm unware if a pre-made setup or framework for such purposes exists (most likely not). So much for the unconclusive answer.
If you just want to probe the user interface with jQuery-like features, then phpQuery might be an option.
If you need to run some Javascript code from PHP, on the server, the spidermonkey extension might be what you are looking for (quoting) :
This extension allow you to embed
Mozilla's Javascript engine
Spidermonkey in PHP.
I've used it -- for fun -- a couple of times, and it was working not too bad ; but note I have never used it in a production environment (and know no-one who do).
You should give mozilla's Rhino a try, if you want server-side execution of javascript. It is a sister project to spidermonkey, written in Java. It was designed to be used in cases where you want syntactically valid client code to run on the server (and, fyi, provides the foundation for google's closure compiler).
It's not an instant solution for javascript-in-php, but as demonstrated here http://ejohn.org/blog/bringing-the-browser-to-the-server/, it can be used for server side testing of client code.
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.
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.