What is an API and how is it different than a Web service? »

Over two years with Sonoa, I’ve talked to customers about APIs for hours every day and see a lot of common patterns. I thought I’d start this blog out by talking a little bit about what we've seen. More companies of all sizes are building web services APIs so that they can make their own capabilities available to a wider audience. The concept of an “API” on the Internet is not new but it’s been taking off, especially recently. At this point, if your company isn’t offering such API, it probably will be before long.

What’s an API? In computer science we’ve used the term “Application Programming Interface,” or “API,” for pretty much forever. Everything from the Windows operating system to the Oracle database has an API. What I’m talking about is a little more specific — a “web services API”. That means some functionality that you can invoke over the Internet. Specifically, an “API” in this context:

• Is invoked over the public Internet
• Almost always uses HTTP (or HTTPS) as its communications protocol
• Often uses XML to represent a response
• Often uses either HTTP query parameters or some XML to represent a request

For these reasons, a good API often requires no special client-side software. The most successful APIs, like the Twitter API, can be used from anywhere on the Internet from literally any programming environment that can communicate using HTTP. The most effective and popular APIs are also simple.

For instance, in order to see the current status of Lance Armstrong on Twitter as an XML document, all I have to do is perform an HTTP GET to this Twitter API URL. And there are tons of examples like this - sites like ProgrammableWeb provide a great directory and stats of many APIs.

Aren’t API’s just web services? Well, yes they are. In fact, all web services match the description I put in the section above except for one thing — a web service does not necessarily have to be accessed using the public Internet. In fact, an awful lot of web services today run inside a corporate network and are never touched by the Internet.

But on the Internet the term “API” has become a lot more prevalent than the term “web service.” that is partly due to semantics — “web service” typically implies “SOA,” which to many people implies “SOAP,” which in turn makes people think, “big, complicated, and expensive.” (And if you don’t know what I was talking about in this paragraph then you probably had the same reaction.)

So from a purely pedantic perspective, an “API” is just a “web service.” But that doesn’t mean there isn’t an important distinction — typically, something called an “API” is designed for the Internet, to be consumed by many different types of clients, and if it is successful it is pretty simple. On the other hand, a SOAP web service running on a big “web services stack” inside a corporate network could be a thing of beauty that is widely adopted, or it could be a tangle of spaghetti that keeps one or two applications intimately intertwined for the foreseeable future.

Why build an API? One short answer is that an API is a great way to get more people to use the services that you offer. For instance, most Twitter traffic comes from its API, not from the web site. (If you’re using a desktop Twitter client like Twhirl or Spaz or even some of the iPhone or Blackberry apps, you’re using the Twitter API.) It also lets you focus on the functionality that your company provides rather than on presentation. Do you run a trucking company with great scheduling and routing capabilities? You can expose those as an API that your clients can embed into their own applications more easily than you can build a slick web site and keep it up to date with the latest fashions in web site design and implementation.

Next time I'll talk about some common challenges we see for folks building APIs. - Greg