Job Board API Standardization

2015, Jul 08    

Like what you see?

Sign up for my weekly newsletter of advice, tools, and news for startup founders and digital entrepreneurs.



Since I published this post in 2015, we’ve done a lot of work on this job board API standardization project and rebranded it. Check out the latest at JobApis.com


A few weeks ago, I wrote about an idea I had to help developers gain access to the myriad job board API’s out there. That blog post generated some interest from my friend and former coworker, Steven Maguire, and with his help, we got the project to a stable version 1.0 release.

The goal of the project remains the same: to make accessing job board API’s easier for PHP developers.

Steven took on the majority of the work rebuilding the core package (jobs-common). He has done work with the PHP League on their OAuth package, which is somewhat similar in nature, so he brought some really good insight to this project. Finding a way to cleanly generalize the many different formats and API styles of the job boards is no small task, but Steven did a great job building an AbstractProvider class to pretty much give you an outline for building new providers. After he had the core package and the Indeed provider, I started putting together more provider packages and together we tackled new issues with the core package as they came up. Setting up new providers is now much easier than it was in my first project.

Some of the key technical features of our Jobs Common package (the core set of classes that each provider uses) are:

  • Schema.org JobPosting Specification - Data standardization is a huge part of this project. One job board API might call their listing title field “job-title” another might call it “title” and yet another “name”. Schema.org has taken on the task of coming up with standard fields that projects like ours can use, so we’ve taken advantage of that.
  • Guzzle 6 - In an effort to become compatible with the newly created PSR-7 spec, we upgraded the HTTP client to Guzzle 6. We aren’t fully taking advantage of streams in large results lists yet, but it sets the project up for improvements in the future.
  • Composer - This was a requirement from the first iteration of the project. Composer allows you to easily include this package in your own PHP project. I’ll be doing some walkthroughs on this blog later to show just how easy this is.

We also added some things to help ensure our tests and code quality stays high. Steven introduced most of these to the project as well, so I’ve got to pass a lot of the credit his way:

  • Scrutinizer - Assesses code quality, test coverage, and documentation.
  • Travis CI - Runs a complete build on different versions of PHP and makes sure there no errors.
  • Versioning/changelog - Obviously should have been done before, but I wasn’t as diligent when working alone.
  • Unit test coverage - I did some unit testing in my original version, but the coverage now is much better.