Based on my experience and previous series about the their APIs Nexmo asked me to write an article for publishing on ProgrammableWeb. Of course I said sure, that sounds like fun. So I wrote about Nexmo’s Verify API that makes end user verification quite simple and user friendly. Head over to ProgrammableWeb.com to read my article: http://www.programmableweb.com/news/end-user-verification-even-your-grandma-can-use/sponsored-content/2015/05/12
In picture - @tjlytle, @prabhuv, @phillipshipley, @Michael_Ludden Just over a week ago I had the privilege of attending the TechCrunch Disrupt Hackathon in New York. I was there as an extension of the Nexmo team to support participants who were integrating with the Nexmo APIs. It was an absolute blast and we had a great time meeting so many talented developers and getting a glimpse into their creativity. I wrote a more detailed post about the experience over on Nexmo’s blog, check it out: Nexmo Disrupting NYC.
This is Part 4 in a series, you can read Part 1 here or Part 2 here or Part 3 here or Part 3.5 here. At this point in this series we have a complete PHP client for the Nexmo APIs. Hopefully I’ve been able to teach some good practices and designs in the process of developing it, but I know many of you test-driven-development advocates are probably screaming that I’ve left out the most important part: testing, and testing early.
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.