At the Forge - Thinking about APIs

People are surprising and unpredictable. In the computer industry,
you hear this in nearly every interview with the designer of a popular
software package. For example, Perl originally was designed for
network programming and text processing. This made it an obvious
choice for Web programming, but Larry Wall certainly didn't know or
expect that when he first wrote the language, years before the Web was
invented.

Users of a software package almost always will push its limits.
That's why some of the most successful and popular programs are those
that encourage users to go beyond the author's imagination. In the
early days of the software industry, such add-ons and plugins didn't
exist, which meant that the only way to get new functionality was to
lobby the authors and then hope the next release would include
the needed features. In the world of open-source software, anyone is
theoretically able to add new features, but between the generally
small number of core developers and the famously loud debates that
sometimes erupt, it can take surprisingly long to add a new feature.
(And although it is always possible to fork a project, this has social
and technical drawbacks that often outweigh the benefits.)

Some programs have a long tradition of encouraging add-ons. GNU Emacs
is best known as a text editor, but it comes with a full-fledged
version of the Lisp programming language. You can create just about
anything you want in Emacs, and people have done so, including
mail-reading programs, Web browsers and an extremely sophisticated
calendar/diary. Photoshop caught on among graphic designers not only
because of its powerful image editing features, but also because of
the large number of plugins that were developed (and sold) for the
platform. Microsoft Office, much as it might be reviled by many Linux
and open-source advocates, became popular because of its built-in
programming language (VBA), as much as for its built-in features. And,
of course, the Firefox browser wouldn't be half as useful to me if it
weren't for the half-dozen plugins that I have added to my software.

So, users push software to the limits, and software publishers have
been able to make their offerings more useful by making it possible to
extend their programs. How does this translate into an era of
Web-based software? And, what does this mean to us as Web developers?

The answer is the increasingly ubiquitous application programming
interface, or API. If you want your Web site to be taken seriously as
a platform, and not just an application, you need to offer an API
that lets users create, modify and extend your application. APIs are
becoming an increasingly standard part of Web-based applications,
but despite everyone's use of the term API, that acronym means
different things to different people.

Starting next month, I'm going to look at the latest batch
of APIs that sites such as Facebook are offering. But this month, I
want to take a step back and consider the different types of APIs that
software publishers offer. This is useful if you intend to extend,
use and work with those APIs. Web development is increasingly a
matter of tying together existing functionality from other sites, and
understanding these APIs can be quite useful.

It's also important for Web developers to understand the nature of
APIs. If you want to create the next Facebook or Google, you're
going to need to create more than a winning product. You're going to
need an ecosystem of developers and third-party software around your
core product. One of the best ways to do this is to create and
promote APIs, letting people use your application as a platform,
rather than a standalone program. By looking around and seeing what
others have done, we can get a better sense of just what the
possibilities are and how we might use them.

Read-Only Protocols

In the beginning, when Tim Berners-Lee invented the Web, he imagined
it as a read-write medium. But for most people who used the Web
during the first decade, it was a read-only medium. You could view
Web sites with your browser, fill out forms with your browser, and
that was about it. There was no API for reading Web sites; if you
wanted to read the content of a site programmatically—for example,
in order to create a searchable index of all Web content—you
needed to create your own “spider” program, as well as teach it to
take apart the HTML.

This changed in the late 1990s, when a number of developers (most
prominently, but not exclusively, including Dave Winer) created RSS,
standing either for really simple syndication or RDF site summary.
In either case, the idea was to create a machine-readable, frequently
updated summary of a site's contents. By checking a site's RSS feed,
you could learn whether there had been any updates. More significant,
RSS feeds were formatted in a standard way, with standard tags, making
it fairly easy for programs to poll a feed and extract only the
information they wanted.

Unfortunately, the term RSS became both the generic term for
syndication and the name for several incompatible (but similar)
formats for syndication. A separate group of developers created the
Atom protocol, which many people believe is superior to all of the
various RSS formats.

RSS and Atom are still popular today. The most common use of these
syndication feeds is for blog and news updates, allowing users to keep
track of which sites have updated their content. But, RSS and Atom can
be used in other ways as well, providing a simple, reliable and
machine-readable version of various types of data from a Web site. If
you are looking to broadcast regularly updated data, RSS and Atom
probably are going to be a good starting point.

For example, the well-known development company 37Signals provides an
Atom feed of recent activity in its Highrise contact management
system. As helpful as it might be to look at your own feed, it would
be even more helpful to aggregate multiple people's feeds into a
single viewer, allowing, for example, a manager to get a sense of what
(and how much) employees are getting done each day.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.