Another option would be PEAR's HTTP_Request2: http://pear.php.net/package/HTTP_Request2.
On Tue, Sep 3, 2013 at 10:49 AM, Coombs,Karen <coom...@oclc.org> wrote: > One project I'm working on for OCLC right now is building a set of > object-oriented client libraries in PHP that will assist developers with > interacting with our web services. The first of these libraries we'd like to > release provides classes for authentication and authorization to our web > services. You can read more about Authentication/Authorization and our web > services on the Developer Network site<http://oc.lc/devnet> > > The purpose of this project is to make a simple and easy to use object > oriented library that supports our various authentication methods. > > This library need to make HTTP requests and I've looked at a number of > potential libraries and HTTP clients in PHP. > > Why am I not just considering using CURL natively? > > The standard CURL functions in PHP are not object-oriented. All of our code > libraries (both our authentication/authorization library and future libraries > for interacting with the REST services themselves) need to perform a robust > set of HTTP interactions. Using the standard CURL functions would very likely > increase the size of the code libraries and the potential for errors and > inconsistencies within the code base because of how much we use HTTP. > > Given this, I believe there are three possible options and would like to get > the community's feedback on which option you would prefer. > > Option 1. - Write my own HTTP Client on top of the standard PHP CURL > implementation. This means people using the code library can only download it > and now 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. > > Option 2. - 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. > > Option 3. - 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. > > I'd appreciate your feedback so we can provide the most useful set of > libraries to the community. > > Karen > > Karen A. Coombs > Senior Product Analyst > WorldShare Platform > coom...@oclc.org<mailto:coom...@oclc.org> > 614-764-4068 > Skype: librarywebchic