The Wheel: Guzzle

Guzzle is an HTTP client library for PHP written by Michael Dowling and a community of contributors. Guzzle is oriented to the quick integration of external web services. Other than this vision, Guzzle has a ton of features relaed to the HTTP protocol capabilities and patterns of usage.

Guzzle is a wrapper but no (leaky or not leaky) abstraction layer: it leverages the power of the curl extension under the covers for performance and simplicity. Other solutions like Zend\Http are available to abstract away the backend that actually performs the requests.

A dive into the features

Guzzle works as a Client object producing requests that can be sent after their configuration.

$client = new \Guzzle\Http\Client('http://guzzlephp.org');
$request = $client->get('/');
$response = $request->send();

The Client object can be injected or created in the objects that face towards the outside of your application through HTTP.
Here are some examples of the included features:

• basic ones: GET, POST, PUT, and all other HTTP methods with headers and body customization.
• Cookie persistence between requests.
• Response cache.
• File uploads (e.g. for testing your own application).

To this you should add everything that curl does under the covers (e.g. SSL, redirects, proxies) but with an higher-level API composed of objects with readable methods instead of being copied from C code.

Architecture

The trio of Client, Request and Response objects constitute the Guzzle's API (and I appreciate the small surface of the Client with respect to the tons of inner workings. The only dependencies present in the composer.json file are the curl extension (of course) and the symfony-event-dispatcher library.

Guzzle supports a static mount, meaning you can configure and call the client with static methods. I understand this can be appealing for retrofitting Guzzle on legacy code, but I strongly suggest you to consider the usage of objects in object-oriented programming.

About the object model, I personally prefer couples of Request/Responses object plus a Channel object responsible for turning one into the other to Guzzle's model of a Client object creating Requests. when you have lots of interactions with heteregeneous external HTTP API, isolated Value Objects as Requests are really easy to test.

However, Client objects have their advantages, like being able to provide defaults for requests such as the host. They're an higher-level abstraction similar to what you can do by using several Channels/Gateway objects for each of the way your application exits on the network (different public web services or endpoint or partner organizations).

Testing

During mocking in unit tests (GOOS) there are two steps to perform, as you have to substitute the client with a Test Double that returns a Test Double for the Request. However, if the Client is used by the Request to send() itself you can try substitute only that object and not the Request itself.

The library is strongly covered by automated tests. One testing capability is the stubbing of static Server objects, so that the requests can be mocked and predefined responses returned.

Integration tests should use all Guzzle features, but talking to a Fake http server (or just a few fake URLs) to exercise curl's code and find out.

Conclusions

The selling points of Guzzle are the load of features it offers, with an easier API than curl_*() functions. My only doubt is the preference for a Client object as the primary abstraction, but you should always wrap these library objects into your own objects so that you can mock and stub freely.