GNIP Spells a Whole New World for Data APIs

Allow me to get nerdy.

It has been a long time since I got downright giddy about something developer-oriented. Lots of new APIs are coming out all the time and I usually take a once over look at them to determine if there is something cool there. A lot of time there are cool things and I promise myself to come back and explore the possibilities later. I rarely do.

However, with the announcement of GNIP today, I finally feel like my incessant mulling of API frameworks might be coming to an end.

Let me back up. A few weeks ago, I was fiddling with a bunch of APIs trying to create some mashup I was working on. I sent Keith a direct message pitching a “crazy idea”. An API for all APIs. One API to rule them all. His response, “A meta API?”

That made sense and made me laugh because I know how much he hates the word “meta”.

My idea quickly dissipated as I realized it was probably pretty futile to create an API for all these varied services that all had different data formats and types and my need for it wasn’t all that important at the time anyway.

I could have also used the concept when I was working on Mokonji, the project that now sits dead because Trackur beat me to the punch.

The idea with GNIP, bringing this story full circle, is that it is a meta-API. It sits in front of “data producers” (Digg, Flickr, Disqus) and provides a standardized API for “data consumers” (Plaxo, MyBlogLog, even Lijit!) to exchange data.

Since this is still so very early, there are bound to be other data producers and consumers. Also notable is that the only data format is XML. XMPP and JSON are missing. That will likely change over time too.

Data Producers not yet involved that should be:

And a few Data Consumers that are also missing:

For PHP Devs, a Twitter PHP Class

At the end of this post, this site is going into a twitter free period of two weeks. I’m sensitive to the fact that we talk about Twitter quite a lot and not always doing a good job of reaching into all of real life like we’d like. So after this post, Twitter will not be mentioned here until June 12. :-)

However, I wanted to get this out the door for devs to knock on and bang out. Awhile ago, I created the dctwits Twitter group and released the generic code. It included a Twitter class created by David Billingham and slightly modified for our use.

A few days ago, I released the WP-Twitterpitch plugin which also used the same class. It’s a very useful class but, to be honest, was a little messy, didn’t support XML and JSON and didn’t have support for all the Twitter API.

So I cleaned it up, extended it, fleshed it out a bit more, brought in Keith Casey as a developer and we’re basically launching the class as a version 1.0-beta today.

I’ll work on documenting things a bit more but there is some basic usage on the site and the code itself is pretty well documented. I need testers to bang on this code and submit issues back, via the Google Code page. Patches welcome as well. And I’d love to see how you use this. You can download direct or via SVN.

When Keith gets done with the DC PHP Conference, we’ll look at pushing it out as stable.

The Art of the Mashup

The other day, I was talking to the CTO of a company that is working to build a web technology solution for a problem that exists due to the arcane infrastructure and systems already in place in the niche target industry. He was mourning the fact that, after spending gobs of time wireframing and re-wireframing a solution, the parties who initially expressed interest in licensing the technology, had decided to walk away from the table for a variety of reasons.

The big conglomerate that had decided to walk had expressed concern over the fact that they already had systems for billing and other management aspects of their company and didn’t want to invest in something unknown and untried over their long-standing, yet antiquated, solution.

Over the course of an hour or so, and even since then, we looked over his wireframes determining what the company should look like in order to make some sales, if not all the sales he wanted. I realized that his product was designed in such a way that dependencies were created everywhere. If a customer wanted just this one portion that does employee management but not the other part that does billing, there was no productive way to do this so he could make a sale without making the big sale.

In the web world, we talk about mashups. Take a google map and mash it up with Twitter and you have Twittervision. Mashup Basecamp with FreshBooks and tie in Salesforce and you’ve got a complete back-office CRM-Billing system to build your company on top of.

The strength of mashups is the distributed nature of the work. I no longer have to store my own video files because YouTube will do it for me and give me a means to access it, thus eliminating the overhead and cost of doing business associated with that video. I no longer have to worry about the development time and money needed to distribute a widget containing my content to other websites because Clearspring does that work for me. The trick is in APIs which allow others to innovate on top of the technologies created by others.

My advice to this entrepreneur was to create APIs between his various modules and build out-of-the-box products that he could sell that utilize those APIs. In fact the APIs can be open and still be paid access, which provides another stream of revenue – especially when his clients have the money to pay top dollar for those APIs if they consider the alternative cost of throwing out entire chunks of their existing infrastructure and using an out of the box solution that may not meet their unique needs.