 |
 |
We're also using Guzzle, and really like it. --Dave ------------------------- David Walker Director, Systemwide Digital Library Services California State University 562-355-4845 -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Karen Coombs Sent: Tuesday, September 03, 2013 3:52 PM To: [log in to unmask] Subject: Re: [CODE4LIB] PHP HTTP Client preference Thanks so much for all the feedback guys. Keep it coming. I'll definitely check out Guzzle as an option. Karen On Tue, Sep 3, 2013 at 4:26 PM, Hagedon, Mike <[log in to unmask]> wrote: > Guzzle++ > > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On Behalf > Of Kevin S. Clarke > Sent: Tuesday, September 03, 2013 8:37 AM > To: [log in to unmask] > Subject: Re: [CODE4LIB] PHP HTTP Client preference > > Another +1 for Guzzle > > Kevin > > > > On Tue, Sep 3, 2013 at 11:32 AM, Kevin Reiss <[log in to unmask]> wrote: > >> I can second Guzzle. We have been using it for our our in-house PHP >> applications that require HTTP interactions for about six months and >> it has worked out very well. Guzzle has also been incorporated as the >> new default HTTP client in the next version of Drupal. >> >> >> ________________________________ >> From: Ross Singer <[log in to unmask]> >> To: [log in to unmask] >> Sent: Tuesday, September 3, 2013 10:59 AM >> Subject: Re: [CODE4LIB] PHP HTTP Client preference >> >> >> Hey Karen, >> >> We use Guzzle: http://guzzlephp.org/ >> >> It's nice, seems to work well for our needs, is available in >> packagist, and is the HTTP client library in the official AWS SDK >> libraries (which was a big endorsement, in our view). >> >> We're still in the process of moving all of our clients over to it >> (we built a homegrown HTTP client on top of CURL first), but have >> been really impressed with it so far. >> >> -Ross. >> >> On Sep 3, 2013, at 10:49 AM, "Coombs,Karen" <[log in to unmask]> 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 >> > [log in to unmask]<mailto:[log in to unmask]> >> > 614-764-4068 >> > Skype: librarywebchic >>