I Forgot My Mantra is Scott Jackson's webtumblespacelog.

Everything Should Have An API

The Setup is one of my favourite websites.

the setup is a bunch of nerdy interviews. what do people use to get the job done?

Awesome computer/internet people are interviewed about the tools that they use to do their work. One of the questions asked of everyone on the site is “What would be your dream setup?” Now, the usual answers involve things like more RAM, bigger monitors, lighter laptops and faster internet connections — all hardware stuff (and, frankly, they’re all things that I’d like). However, al3x had a different answer that got me thinking:

I want better software: more usable, more accessible, more open, more secure, more integrated, more seamless.

That was the springboard for my grand statement:

Some definitions for the uninitiated (and some reminders for the familiar):

API (Application Programming Interface): a way of exposing the things you do in your application so that developers writing other applications can get information out of your application.

Scriptable: Having the ability to control one or more software applications automatically through a series of commands.

The Unix Philosophy:
- Store data in flat text files.
- Make each program do one thing well.
- Write programs that work together.
- Expect the output of every program to become the input to another, as yet unknown, program.
(Note: this is a brutal summary of some seriously classic ideas.)

If each program had some way for me to access it, some way for me to automate it and some standard, simple way for me to manipulate it, here’s the kind of thing I could do with my computer:

Log in to my bank’s website securely. Using their API, get details of all of my recent transactions for my Savings account. Store those details in a nicely-formatted (i.e. human-understandable and computer-parsable) plain text file, encrypted if necessary. Pipe the contents of that file into a graphing program and graph my account balance over time. Save that graph as a nicely-formatted text file such that, when it is passed into the graphing program, it produces that same graph again.

The point here isn’t to say that “well, Scott, your bank already has a crappy web application that makes a graph of your Savings account balance over time.” The point is that every single step in this process is interchangeable with something else. Want to graph how many Twitter followers you have over time instead of your bank transaction details? Just swap the text file of transaction details for a text file of your Twitter follower details and the application logic still works. Hell, graph your Twitter followers against your bank account balance! Want to use the bank transaction stuff in another application (maybe a Dashboard widget that tells you how long you’d have to save your money in order to buy an iPhone 3GS unsubsidised based on the current growth rate of your account balance)? Well, just take that bank transaction API and the data it gives you and use it in your iPhone savings application!

This is the kind of orthogonality that Andy Hunt and David Thomas talk about in The Pragmatic Programmer — code should be swappable, code should be reusable.

Here’s another idea:

I’m writing a webapp for making timetables for university students. What I want is for a user to type in the courses they’re taking that semester and then have the webapp give them back a list of possible timetables for that combination of courses. So, to do that: go to the university’s website and get the data (as a nicely-formatted text file) on class times for the courses the user gave. From that, look at all the different combinations of timetables that are available for those classes. Return all of the timetables that fit the user’s criteria (e.g. “no classes before 10am all week” or “Must be finished by 4pm on Tuesdays”).

The same thing applies here — if the university website had an API for retrieving timetable data for courses, a Facebook application could set your Facebook status to “In a lecture for X”, where X is the name of the course you’re currently in a class for. (Admittedly, that isn’t a great idea — I’m pretty sure there’s enough quasi-spam on Facebook already.) Alternatively, for that awkward first week of classes every semester, you could have a webapp get the class times for your courses, put them in a list and give you directions around the campus to help you find the buildings/rooms that your classes are in. That’s the kind of stuff you could do with a university website that gives you access to details as trivial as class times. Unfortunately, my university does not give you access to that kind of information, so the options are to either find out all of those details myself and put a copy of them into my application (which would require me to update all of the class times each semester) or get the user to manually go to the university’s website, look up the class times themselves, then go back to my webapp and type in all of the class times for their courses. Neither of these is anywhere near an ideal solution.

Here’s another one:

Go to the government’s public transport website and get the bus timetable for the bus going to and from my university. Look at all of the times the bus comes past my nearest stop on its way into uni. Take those bus times and (after storing them as a nice text file) add them as events on my Google Calendar in a new calendar called “Buses to Uni”. Or, instead of adding them to my calendar, tell me via a Growl notification when I ask how much time there is until the next bus to university comes past my bus stop. Or, send me a push notification on my phone when there’s only one bus left that will arrive at university before my first class.

Here’s yet another one:

When my alarm clock goes off in the morning, get the latest tech news podcast (downloaded overnight) from my computer via WiFi or a wired network connection. Play the podcast through the alarm clock’s speaker/s. If I hit “snooze” on the alarm clock, pause the podcast. Once I stop the alarm, remember where I was up to in the podcast and give that information back to my computer. Now when I go to listen to the podcast while I’m eating breakfast, it will continue playing where it left off.

You get the idea.

I want everything to work together. I want there to be standards for the way that things on the internet and on local machines interact. I want a lot more things to be automatable. I want developers to refer back to ideas like the Unix philosophy and constantly hold their software up to the standards that it lays out.

To extrapolate this idea even further, imagine if everything in the world followed the rules I outlined here. Imagine if watering the garden was scriptable. Imagine if your desk lamp had an API. Imagine if your bookshelf and its contents were stored as a searchable, manipulatable text file.

My laptop computer has a 2.4GHz dual-core processor in it. It is capable of computing 50-kajillion things every second of every day for years and years, but until everything can access everything else, it’s not as useful as it could be. Right now, hardware isn’t the bottleneck in getting things done with computers. It’s less-than-great software that doesn’t play nice with others.