WordPress.com Stats API

I wrote this the other day and forgot to post it:

I absolutely love the WordPress.com Stats plugin, for keeping an obsessive track of all the clicks and searches through to my posts. What it’s missing however, is an API.

When is Automattic going to give this package some loving? It has heaps of places it could be improved (the graph is horrible how it changes scale all the time) if only we had some access to the data feed.

Seems that Automattic has updated the stats display at the very least with a brand new stats interface. Now for the API guys!

Wordpress.com Stats Graphs

APIs are Hard but fun

Currently I’m working on an abstraction layer for the Google Maps API, this is purely written in Javascript, allowing any language to produce JSON objects and pass them quite seemlessly onto a Google Map. Originally this was planned to be able to be used across maps APIs (Virtual Earth, Yahoo Maps) but has descended into just being Google Maps – to begin with anyway. Currently the plan is to provide a set of handlers that know how to process specific datatypes and interact with the map ie. placing the markers, drawing the routes and monitoring changes. I think going forward, this can really help us at Xebidy move quickly, building rich location based applications very quickly.

It has been mentioned a number of times recently (though I can’t think who, probably John Resig) that building API’s is hard and I can’t help but agree. While it’s definitely challenging, I think it can be an extremely rewarding thing to get right. Developers really do feel the benefits of having a well thought out APIs with productivity gains and less headaches.

One of the biggest curses yet greatest benefits of using Javascript is the many ways you can morph the language. Using ‘apply’ and ‘call’ you can provide a developer down the track some powerful built-in functionality. Throughout the XEMap API I’ve tried to avoid any developers ever instantiating a handler of their own (no new XELocationHandler). This lets me rewrite the this variable whenever or however I please. To store configuration variables I pass an options array to each function. This in turn leaves those functions to be reusable out of the context of the API.