Published in Application Programming Interfaces on Monday, November 7th, 2005

The latest trend towards building web based applications has brought with it an increased number of application programming interfaces (APIs). The programmer in me decided that it was about time that I had a play with some of the offerings.


This post forms part of a series on APIs. Read the background on the API series.

Application Programming Interfaces

For the uninitiated, the term API can be a little daunting, but they need not worry. Lets have a look at Wikipedia:

An application programming interface (API) is a set of definitions of the ways one piece of computer software communicates with another. It is a method of achieving abstraction, usually (but not necessarily) between lower-level and higher-level software.

Web Based APIs

When looking at the web and web based applications, an API can simply be thought of as a method of interacting with an application whereby you send it an HTTP request and it returns something to you. This allows an application (webpage whatever) to use, for example, Google search results - thru the Google API - in their own application.

For further thoughts and examples on Web APIs, I strongly encourage you to have a look at the sample chapter (pdf) provided from Professional Development with Web APIs : Google, eBay, Amazon.com, MapPoint, FedEx and Top Ten FAQs for Web Services over at O'Reilly.

Note: Pretty much everything that I want to say in this article can be found in those links above, and the .pdf provides a great down to earth view of web applications and services.

Using APIs

Most API providers (e.g. Flickr, Yahoo!, Google, Amazon) require you to apply to use their API and to get a developer key. The key is simply a token that, when embedded in your request to their API, allows them to identify who is using their system and regulate usage. Most of the providers offer documentation and code examples.


One of the things that is not consistent between APIs is the method used to communicate between systems. Some, like the Google API, use SOAP (specs, W3Schools, Wikipedia), while the Yahoo! API uses REST (Wikipedia) and Flickr uses either of the aforementioned pair and also xml-rpc.

For the sake of understanding, I'll overly simplify things and say that each of those acronyms represents a slightly different way of passing requests and data from one server to another using http and xml. So although they have different names and specifications, they also have similarities.

Moving forward

As mentioned above, this series of posts won't be anything too complex, at least to begin with. I have the first few articles planned out and based on feedback from users, we'll see where this goes.

We'll be starting out this week by playing with the three big search APIs (Yahoo!, Google and MSN), with the goal of getting comfortable making requests for data and then parsing it for our own use. Look for the first article this Wednesday!

Comments and Feedback

I too become daunted just knowing that I will be "handed an API to work with"
Truth be told, there is such thing as a "bad API". In contrast, a good API is one that you need not know the framework in which an API was architected to do what you need to do. A simple document showing examples and references to functions and methods and what they can do for you is mainly all you need. Anytime you need to dig deep into the source of the application framework, then that, my friend, is a bad API.

No doubt, well put Dustin. This is great:

a good API is one that you need not know the framework in which an API was architected to do what you need to do

Thank you! Ahhhh finally someone will overly simplify this concept. I’ve come across so much documentation out there, but the shear size of it always frightens me off. ;-) In the meantime, I’ll be waiting in anticipation to your series.

Great to hear John, always good to know that people are interested :-)

Hey Mike,

Thanks for helping to get the word out about APIs. We're going to release an API for our new web app, DropSend, and I'm excited to see how people will use it.

I've spoken to Cal Henderson of Flickr quite a bit about their API, and it's been interesting to see how people are both innovating, and abusing the API, all at the same time. I think their API Explorer is amazing.

Thanks again fro the API series - great stuff!

Hey Ryan, thanks for stopping by!

APIs are fun, and prone to abuse, for sure. I'll have to keep an eye on what you all have to offer over on Drop Send...

Don't suppose you could get Cal out to London could ya?

Home » Blog » Web Development » Programming and Scripts » Application Programming Interfaces

Check out the blog categories for older content

The latest from my personal website,
Mike Papageorge.com

SiteUptime Web Site Monitoring Service

Sitepoint's web devlopment books have helped me out on many occasions both for finding a quick solution to a problem but also to level out my knowlegde in weaker areas (JavaScript, I'm looking at you!). I am recommending the following titles from my bookshelf:

The Principles Of Successful Freelancing

I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.

The Art & Science Of JavaScript

The author line-up for this book says it all. 7 excellent developers show you how to get your JavaScript coding up to speed with 7 chapters of great theory, code and examples. Metaprogramming with JavaScript (chapter 5 from Dan Webb) really helped me iron out some things I was missing about JavaScript. That said each chapter really helped me to develop my JavaScript skills beyond simple Ajax calls and html insertion with libs like JQuery.

The PHP Anthology: 101 Essential Tips, Tricks & Hacks

Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..