Everything Should Have An API

I agree with 95% of what he says, but I'd make one change to the Unix philosophy: text files aren't the best primitive.<p>Text files have a super low-level API (stat, seek, read). I think the system he describes would be much more usable if he picked slightly higher-level data abstractions. I would recommend Python's built-in types: list, tuple, dict, set. Most data can be easily represented by these types and they provide a higher level API than streams (files), which means the barriers to using them are much lower.

The printing press enabled more people to read, though still few could write. The net has enabled more people to write, though still few can program. A net where everything has an API is an extremely helpful step in creating a system which enables more people to program.

The scenario descriptions are distinctly reminiscent of Berners-Lee's scenario descriptions for the 'semantic web' several years ago. Of course, that is now rather out of fashion, but not entirely justifiably. The 'semantic' angle was somewhat fanciful, but the core idea was <i>the data web</i>: It is one thing to put APIs on everything, but another for all the data types and formats to work together. That was more the aspect that RDF was addressing. It is neither thoroughly convincing nor completely apposite, but worth factoring in to the consideration anyway. (The essential RDF concept was elegant, whatever anyone says.)

Having a good API for everything would be almost as good as The Singularity (tm), but making a good and secure API is very hard and comes with a massive hidden cost.<p>1) An API can require even more planning to design than the application or service itself.<p>2) Mistakes made in the design or implementation of the API turn into liabilities you can't solve without breaking users of the API.<p>3) The cost of maintaining an API so that it and its documentation doesn't fall out of date with the app/service can be as high (and sometimes even higher) as the cost of maintaining the app itself.<p>4) It widens the attack surface.<p>And those are just the ones off the top of my head.

Should creating email accounts have an API? How would the captcha be presented? How about adding reviews of products?

I want, I want, I want. How about you propose how this should be done? It's harder than it looks, and no, Unix is not the one-and-all answer to everything.<p>Take one of his example scenarios:<p>"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."<p>This has a number of hidden assumptions:<p>* What is "the latest news podcast"? One user-selected source, or a blended filtered combination, or a crawled set selected based on previous behavior?<p>* How does a (not <i>the</i>!) computer know how to talk to the alarm clock? I hope I don't have to create a home network myself, cause I know my Mom certainly can't. How is this connection authorized? What happens if the power goes out on the computer - what will the clock do? What if the clock batteries fail - will the computer play the podcast instead?<p>* Is the saved position synced only the one source computer (I hope not). What if the network to the computer is down - can the alarm clock sync somewhere else?<p>* Can I resume listening to the podcast on a different computer at breakfast? My partner/sibling/friend's computer? How do I log in? How is the position data saved along with my identity? How does the breakfast computer address the first computer, or the alarm clock?<p>The problem here is not access to the external APIs (not that hard) but federation, identity management, authorization, privacy considerations, and addressing between these disparate systems. Proposal adopting existing standards for these requirements, or new proposals for standards are, of course, appreciated.

As previously said, the financial incentive is simply not there. As much sense as it makes for you to have easy access to your information, there are too many businesses that rely on controlling that access.<p>On the other hand, tools to do this with almost any site already exist. RSS is common enough, and where it doesn't exist, screen scraping isn't that hard (and getting easier all the time). If I'm not mistaken, this is the exact problem that Yahoo pipes are trying to address.<p>Of course, sites that require a complicated login process (banking sites) are still out.

As right as you are, making an API for your service so people can replace your crappy interface with their own good interface probably isn't the best business decision. Online banking sites can display ads. The bank can't inject ads into another client though.<p>Also consider that the bank would get blamed in popular opinion if someone wrote an insecure client that was determined to be leaking data.

For my own personal use I think text based interfaces (with pipes) are superior, the higher level pluggable components in AppleScript/Automator seem more usable in general.<p>That said, there was an excellent article recently with the experiences of a trainer in getting people to use *nix, who found the minimalistic "command mode" more usable due to it's text oriented simplicity.

I want a build system with an external API.

API is kind-of a misnomer in this case. API implies each service has its own set of rules, the data is open, but the access is different.<p>Everything should talk to one another, but a service's name or url should never have to appear in any code. That's the user's job to input.

Yes. I was just doing my college applications and thinking this exact thing. The Common Application would look like a piddly idea if the college application process just had an API.

Personally it sounds like a security and privacy nightmare to me.

Couldn't agree more. This is what my next startup is based on.

They shouldn't just have an API, they should use the same APIs where possible. Each site having it's own API is a major barrier.

for anyone who hasn't seen it, <a href="http://www.ted.com/talks/tim_berners_lee_on_the_next_web.html" rel="nofollow">http://www.ted.com/talks/tim_berners_lee_on_the_next_web.htm...</a> provides a nice context

well, most data is exposed via a website, so if the api doesn't exist, just mechanize it. its not really feasible to rely on goodwill for these grand visions.

This is ridiculous, we can't just let people have access to their data!... i mean OUR data. Just imagine, they may learn things we could have forced them to pay absurd fees to get! :P

But at what cost?