Building an embeddable REST API Console

One of my latest projects is an API to access the beer inventory put online by the Utah DABC.  I’ll save the details of that project for another post, but in the meantime you can check out the code on Github.

After making some decent progress, I started to think about how best to share it with the world.  Having worked with many APIs over the course of my programming life, I realized that the ones I enjoyed the most and achieved the quickest success with had one thing in common: an interactive console.

Twitter was the first example that came to mind.  Their console is powered by Apigee, and in a rare failure of my Google-fu, I came to the conclusion that the Twitter API must also be powered by Apigee and the console feature is reserved for paying customers.  (This assumption turned out to be false.)

It then occurred to me that the REST API had it’s own console, and that the company responsible for it had a good track record of open sourcing their work.  I was able to find this blog post about the original console, and subsequently the Github repository with the source code of the current version.

Much of the code is tied to either the domain or the architecture of the API itself.  I took a “bare minimum” approach to modifying the console for my own purposes; turning the root endpoint into a configuration variable, and creating an “authentication provider” that didn’t actually authenticate.  You can see the changes I made here.

Even with a basic API, the result is beautiful:


Restify – Specify API Version in URL

Recently, I started a project to build an API for the Utah DABC‘s online beer inventory.

After researching a few NodeJS REST frameworks, I selected Restify because it’s dead simple to use, supports CORS and versioning out of the box, and has a Redis-based response cache plugin available.

I wanted to specify the API version in the URL, but Restify only natively supports the Accept-Version HTTP header.

This Stack Overflow answer suggested a middleware approach to map a version URL prefix to the Accept-Version header, but it didn’t work correctly for “partial” version paths like v1 and v1.0.

Here’s the version I modified to work as I expected:

// allow path based API versioning
// based on
server.pre(function (req, res, next) {
	var pieces = req.url.replace(/^\/+/, '').split('/'),
		pathVersion = pieces[0],
		semVersion = semver.valid(pathVersion);

	// only if you want to use this routes:
	// /api/v1/resource
	// /api/v1.0/resource
	// /api/v1.0.0/resource
	if (!semVersion) {
		semVersion = pathVersion.replace(/v(\d{1})\.(\d{1})\.(\d{1})/, '$1.$2.$3');
		semVersion = semVersion.replace(/v(\d{1})\.(\d{1})/, '$1.$2.0');
		semVersion = semVersion.replace(/v(\d{1})/, '$1.0.0');

	if (semver.valid(semVersion) && server.versions.indexOf(semVersion) > -1) {
		req.url = req.url.replace(pathVersion + '/', '');
		req.headers['accept-version'] = semVersion;

	return next();

Note: this approach requires node-semver.

Patch to WordPress for iPhone Accepted!

I recently started a new job at Voce Communications, working on custom WordPress setups.

One of the many perks at Voce is the opportunity to contribute back to open source software.

In some rare free moments, I was able to add HTTP authentication to the WordPress iPhone app, which had been on the ‘future enhancements’ list for quite some time.

I’m really quite elated that I now have code in the App Store, and that I could help such an awesome OSS community.

Feel free to view the patch submission, and mention on the WordPress iPhone blog.

HTTP Auth ButtonHTTP Auth Entry

Code Tennis: Volley 2?

Ok, so Pete got back to me with his volley, albeit incomplete.

For never touching Objective-C or Cocoa in his life, he took on a rather ambitious volley: turning my simple “speaking magic eight ball” into a speaking RSS feed reader.

He found Apple’s Publication Subscription framework, and went to town trying to get it to work. I took a quick look at the code, and it seems I’ll have to do some reading in the documentation before I can fix it.

Hopefully this doesn’t spell the end for our Code Tennis match..

Check out the code on github.

Playing Code Tennis – First Volley!

A few days ago I came up with an idea for collaborative/competitive programming after seeing a match of Layer Tennis.

I’m sure you can see where this is going… yes, Code Tennis!  A quick google showed me that some other people had this idea before me, and setup a nice looking website, although no one is using it.

Code Tennis has some cool features: Twitter notification of volleys, bitchin’ graphics, and a timeline of commits/volleys.  I just hope that it all works as expected since it doesn’t look like the creators have had any external testing yet.

I’m playing my friend Pete (his site). So far the only ground rule is that the app has to be a Mac desktop app (NOT document based) written in Objective-C.

First Volley before click
First Volley before click

My first volley (above) is a Magic 8 Ball that uses the OS X speech synthesizer to “say” the 8-Ball’s response.  I can’t wait to see what Pete does with it!

First volley after click
First volley after click

Updated SPE package for Mac OS X

I haven’t written a ton of python. and what I have isn’t very pythonic.

An IDE that really helped me out when I did write said python was Stani’s Python Editor (SPE).  It has a host of useful features including (but not limited to) debugging, UML, GUI creation, and Blender support.

Without modification, SPE is simply a .py to be executed, which can be a bit cumbersome on OS X where you may be used to launching apps via the dock or spotlight/quicksilver.

Over on Stani’s blog, Krzysztof Olczyk posted an OS X packaged version of SPE.

I have simply updated the version to reflect the latest as of this post, which is 0.8.4.h

If there are issues, check the forums over at Berlios, or contact me.

You can snag it here.