We are proud to announce a new release of the php-sparkpost library at version 1.0.0! After receiving feedback from the community, we have dramatically overhauled the library to be easier to use and more flexible.

One of the biggest changes that we’ve made in this release is the use of HTTP adapters. Since the library is built on top of the SparkPost REST API, one of the biggest challenges that we faced in previous versions was the ability to use our library with other libraries that also made HTTP requests. We had originally chosen to ship our client library with Guzzle, a popular HTTP request library, but this unfortunately came with the side effect of version mismatches and dependency hell for our users.

Enter HTTP adapters. HTTP adapters allow us to present the same interface to the user and allows us to use the same interface within the library for any HTTP request library or tool that the user decides to implement. The user simply has to instantiate an adapter for the library that they are using and pass it into the SparkPost constructor when they instantiate it. We use the Ivory\HttpAdapter library which is PSR-7 compliant. PSR-7 is a specification for HTTP message interfaces in PHP.

The second major change is that we switched from a static interface to an instance based one. This doesn’t change much for the end user of the library besides only needing to include one package instead of two and swapping a few ‘::’ operators for ‘->’ operators, but between this and the adapter changes mentioned above, this version isn’t a simple drop in replacement for previous versions (which is why we’re releasing as v1.0). However, as the library’s toolset grows, we hope these changes offer developers the ability to access all of its functionality from a single reference and with a shared configuration across all of those tools.

Here is a simple example of sending an email with SparkPost after setting it up above:

We also added a new feature to be able to use the library to take advantage of other API endpoints that aren’t currently supported. We do this with a new ‘setupUnwrapped’ method passing in the endpoint name. Doing so exposes basic create, update, get, and delete methods which will support bodies and parameters outlined in our API documentation. This is a little hard to explain but it may be easier to see with an example: