Skip to: Navigation | Content | Sidebar | Footer

Full Archives

The Web Really is an API

November 29

Every so often I'm reminded of how the simplicity of the web is belying of the underlying power.

Generally speaking, the web provides a simple user interface that has the ability to power increasingly complex back-end interactions. The more I delve into the nuts and bolts of how things like HTTP work, the more I realize that the implicit transparency of it all creates prime opportunities for even know-nothing coders like myself to build more and more sophisticated interfaces and applications.

Once the data hits the server it's mostly smoke and mirrors to me. But the data that hits the client side is quite transparent, and easy to tweak at will. The web is built on View Source, Open Source, and transparent URIs.

For example, the more I use Movable Type, the more I end up routing around the scripts and code that are provided out of the box. I'm creating my own interfaces for common tasks, customizing for my own preferences and improving where I see fit.

Case in point, the tweaked search page on this site which uses PHP to move beyond the limitations of MT's built-in templating (made possible thanks to the HTTP get method), or the tweaked comment preview pages which tap directly in to the common templates used elsewhere throughout this site, and allow PHP usage on those pages (something you don't get out of the box).

Article Buttons

Now thanks to View Source and the ability to trigger actions via a hyperlink, I've been able to litter this site with hooks back in to the MT interface to perform common actions, from the pages on which I wish to perform them.

For example, on every page what I now see is a list of actions running down the sidebar that allows me to do things like jump directly into the comment editing and clear the activity log. When I visit an individual article page, I get a set of buttons that allows me to perform actions like edit the original article or rebuild it (or even outright delete it if I'm so inclined).

I see them because I have a cookie set on my hard drive:

setcookie ('aCookie', 'aValue', time()+31536000, '/');

You don't see them because the PHP that checks for that cookie selectively hides them from you:

if ($HTTP_COOKIE_VARS["aCookie"] == 'aValue') {
  // here's where the good stuff goes

This is nothing revolutionary, and WordPress and others have had this type of functionality for ages. It's not the final result that's important here, it's that a non-coder like myself could whip this up in a matter of a few hours (including button creation time) simply by observing output and modifying it accordingly.

The MT interface works based on simple hyperlinks, each performing an action with data being passed to and fro via querystrings. I grabbed the relevant links straight from the interface. There was nothing saying I couldn't just right-click -> Copy Link to Clipboard and then use that URI on another page, which was exactly what I did. In cases where variable data was being passed via querystring, it was a simple matter of replacing things like Entry IDs with their programmatic equivalent.

The importance of this isn't to say hooray me for hacking up Movable Type (although I am rather pleased with how far I've been able to extend it). Rather, the concept of observing the data being passed to the client side, and then manipulating it and sending custom data back to the server in a form it expects, is basically a (poorly documented) front end API in and of itself.

An API, or Application Program Interface, is a set of routines that form the basic building blocks of an application. Web sites have been making use of APIs for years, e.g. Google and Amazon.

Theoretically it's not even necessary to see what's happening inside the server. A web browser exposes all the information passed to it, and viewing the source nets server variable names. It's even easier when the HTTP get method is used, since the variables are right there in the URI.

All this transparency means these pieces of data can be used elsewhere. With a bit of trial and error, and assuming there's nothing in the script specifically blocking the practice, there's no reason why an entirely new front-end interface couldn't be built for any number of web-based applications and services.

But as for what the server does after receiving the data though, well, that's what a more formal API is for.

(The title of this article is, of course, a reference to Joel Spolsky's infamous "How Microsoft Lost the API War".)

Permalink › | 20 comments

Behind the Scenes

November 22

Cameron Moll wants screenshots again. I completely missed the last round, so I thought I'd throw my hat in the ring with this peek at the editing process.

Ugly Editing Session

This is editing in all its glory. Notes and deletions, insertions and corrections, it's all in there. Word tracks changes as everyone involved makes them, so no text ever goes truly missing—it's just removed for production purposes. This is a particularly fun example due to the large amount of stuff going on. The inline highlighting can also be turned off, and for the most part it's impossible to follow along after a few paragraphs of this so I generally do so.

We are aware that Word has a comment feature that's much less potentially harmful to the production process, but this is how the New Riders style guide recommends inserting notes. I say potentially harmful, because it's possible one or two of these may slip through the production process and make it into the final text. Maybe I'm alone in this, but I love finding little production mistakes like that in other people's work; it's like an Easter Egg in a book. And having said that, I'm sure I've just doomed ours to more than our fair share.

How's progress? Coming along nicely. I guess I'm more or less done writing, now we just have the editing and reviews. We're not too far off our estimated delivery date, and still aiming for a January release. (The date on Amazon is wrong, and always has been—sorry about that, not much we can do but wait for the update.)

Permalink › | 17 comments

Checking In

November 11
Progress: Book, 90%. Everything else, not so much.

I'd apologize, but for the fact that those numbers are exactly where they need to be right now.

In lieu of anything more to discuss at the moment (despite the growing backlog—later, later, always later, I say, until it's inevitably too late) let's try something new. You ask, I answer. Use the comments for anything that happens to be on your mind, and I'll see what I can do to reply.

Ground rules: keep it clean, and keep it friendly. Dumb questions will be responded to in kind. Questions that require shorter answers are more likely to get a reply. And whatever you do, don't ask about the Apple curse.

Update: That was a fun diversion, after months of technical writing some "fun" writing was exactly what I needed. Thanks all. Comments now closed.

Permalink › | 117 comments