PHP Code Libraries for our web services

A couple of weeks ago I posted to the OCLC Developer Network and code4lib listservs asking the developer community what their preferred HTTP Client was for PHP. I have been working on code libraries in PHP to make it easier for developers to interact with our web services. These libraries will provide working examples and solve some of the more rote tasks, such as Authentication and Authorization. The first library we are hoping to release will wrap up the functionality for interacting with our Web Service Key (WSKey) API key system.

Choosing a PHP HTTP Client

All of these code libraries have to make HTTP requests and I didn’t want to do this natively using PHP CURL, which isn’t object-oriented. I proposed three possible solutions:

  • Write my own HTTP Client on top of the standard PHP CURL implementation. This means people using the code library can download it and not worry about any dependencies. However, that means adding extra code to our library which, although essential, isn't at the core of what we're trying to support. My fear is that my client will never be as good as an existing client and it introduces the possibility for bugs in our library.
  • Use HTTPful code library (http://phphttpclient.com/). This is a well developed and supported code base which is designed specifically to support REST interactions. It is easy to install via Composer or Phar, or manually. It is slim and trim and only does the HTTP Client functions. It does create a dependency on an external (but small) library.
  • Use the Zend 2 HTTPClient. This is a well developed and supported code base. The biggest downside is that Zend is a massive code library to require. A developer could choose to download only the specific set of classes that we are dependent on, but asking people to do this may prove confusing to some developers.

Ultimately the first and third solutions were not popular. Most people were in favor of using an existing code library. However, Zend was considered bulky and onerous to deal with. Two alternative HTTP Client libraries were suggested:

 

  • Guzzle - http://guzzlephp.org/
  • PEAR's HTTP_Request2 -http://pear.php.net/package/HTTP_Request2

I’d looked at PEAR’s HTTP_Request2 as part of my initial review but somehow had missed Guzzle. Since Guzzle was recommended by multiple members of the community I decided to do a deeper dive and look at it in more depth. Ultimately after my review I chose to re-implement my HTTP calls using Guzzle.

Why Guzzle?

  1. Some major code bases are powered by Guzzle. Guzzle powers the official AWS SDK for PHP and Drupal 8 core incorporates and uses Guzzle.
  2. Strong tests. Guzzle uses PHPUnit for testing and I was impressed with their level of test coverage.
  3. Multiple ways to install. Guzzle can be installed via Composer, PEAR, a phar, or manually. I really like this as it allows people at different levels to start using the code base.
  4. Public repository for code base. All the code is up in GitHub which is super advantageous both for reviewing the code and contributing corrections or enhancements.
  5. Enhanced features and functionality. Guzzle has some features and functionality that don’t exist in other code libraries I’ve looked at. For testing and debugging purposes Guzzle\History Class is incredibly useful because it enables code to be written which keeps a history of your HTTP requests. When you’re dealing with a web service interaction that might actually be made up of several HTTP requests, as is the case with our web services, this feature is highly desirable.

What’s Next?

Now that I’ve settled on using Guzzle to power the HTTP request part of my code libraries, I’m incorporating it into the code base. Ultimately this means changing 50 to 60 lines of code in three different files and testing the functionality. Because I need the trunk code to still work (I use it for testing all the time), I’ve cut a branch to work in. Once the work is completed and tested, I can merge the changes back into trunk. The next step will be getting the authorization and authentication classes ready for release. This means

  • Finishing adding tests with PHPUnit
  • Getting the intellectual property and license questions resolved
  • Making the source code available via GitHub
  • Creating a PHAR
  • Making versions available via

    • Composer
    • PEAR

You can see from this list there is still a lot of work to be done. Many of these tasks I’ve never actually done before. While I’m excited to get to learn about these things, it will slow the process down a bit. Additionally, I’m about to go away on maternity leave! This project will be my focus when I return in late November and our hope is to get things released around the first of the year. Watch this space – we’ll update you on our progress as we get closer to releasing these libraries.
 

  • Karen Coombs

    Karen Coombs

    Senior Product Analyst