The Boring Blog of Phillip Shipley

This is a small follow up on Part 3 in a series, you can read Part 1 here or Part 2 here. In Part 3 of this series we completed API clients for Nexmo’s SMS and Number Insight APIs. Today I implemented the rest of the clients for Voice, Number Verify, and Developer APIs. As I’ve hit on several times, using the Guzzle Web Service description way of developing an API client can save a lot of time.

This is Part 3 in a series, you can read Part 1 here or Part 2 here. Ok, quick recap: in part 1 we explored what API calls to the Nexmo API look like to send an SMS and a few ways we could write them. Then in part 2 we built out the ground work for a Guzzle web service client and implemented the Send SMS API with it.

This is Part 2 in a series, you can read Part 1 here. In Part 1 of this series we laid a foundation for consuming the Nexmo SMS API and covered a few ways to interact with it. In this part we’ll create the actual Guzzle Web Service Client to interact with it to demonstrate how simple it can be. The first thing we’ll do is get our project space ready by creating a folder (these steps assume you’re working on a Mac or Linux based system):

Phew. That was a long title. Sorry about that, just wanted to try to be clear on what this post (series of posts) is about. Recently I’ve had the need to write several API clients to simplify integrating with services like CrashPlan, Smartsheet, Trello, etc. Initially I started writing a client library that used the standard Guzzle features. After writing a couple of them I remembered a talk by Jeremy Lindblom @jeremeamia at last years php[tek] conference.

Wordpress is pretty awesome, but sometimes it just doesn’t do exactly what you want. Thankfully the API is pretty extensible and you can change just about anything you want. Right now I’m working on a site for a department at our organization and for their site they really need to host four sites (sections) in a single install. They would like to have a global navigation element to click between the sections but then they want each section to have its own main navigational menu.

For must of my time working at WebEx I was either support or developing with their APIs. The WebEx APIs are used to schedule meetings, create users, gather history information, etc. I can’t tell you how many times I wrote new code to do the same things. So when my current project with Sumilux came about to write integrations for Cisco WebEx, GoToMeeting, and BigBlueButton APIs we decided to just write one library to integrate with them all.

Remaking the WebEx Free Trials - php|architect September 2011 In November 2010 I had the privilege of speaking at ZendCon, the largest annual PHP conference. I gave a talk about a success story of mine at work using Zend Server and Zend Framework to rebuild our free trials engine. It is a story I am proud of and the work we did continues to serve us well today.

I’ve been working on refactoring my adapter to prepare for supporting many of the features I discussed in my previous post. Involved in the refactor was moving code that should be common to any of the realtime translation adapters to a common parent class, Shipley_Translate_Adapter_Realtime. So now the usage is a little different when creating the Zend_Translate object, but the usage within the view remains the same. Also in this update I’ve added some Zend_Log support for Zend_Log_Writer_Firebug so that I could easily do some debugging while moving all this code around.

A couple weeks ago I saw a tweet come across the screen by Derick Rethans (the guy behind xdebug) about how he is translating tweets related to xdebug to better understand what people are saying about it: New blog post — Translating Twitter: http://derickrethans.nl/translating-twitter.html — Derick Rethans (@derickr) January 5, 2011 This gave me an idea about writing a Zend_Translate_Adapter that can do the same when the requested content is not found for the given language in local translation sources.