"Application Programming Interface"
We use APIs to enhance our sites, in a few different ways. Functionality: We use APIs to outsource part of our application’s functionality to someone else, so we can focus on the unique bits. Public Data: There is a huge amount of data available, and APIs make that data available to use in a structured way. (Google Maps API) For example, I don’t particularly want to install a database of the world’s addresses and algorithms for searching them on my server -- I’d much rather just use the Google Maps API to geocode an address. User Data: We also use APIs to access data from other products and integrate them with our own. Users use multiple products and expect for them to work together - synergy. APIs can be quite useful, so we need to understand how to best use APIs, and this is a talk about how client-side APIs work, what APIs are out there, and why you should use them.
Many different ways to bring in content from other sites using HTML and JavaScript.
IMG | 1993 | Mosaic |
SCRIPT | 1995 | Netscape & Sun (RIP) |
IFRAME | 1996 | Microsoft |
OBJECT/EMBED | 1996 | Netscape/W3C |
XMLHttpRequest | 1999 | Microsoft/W3C |
By definition (or atleast by my definition), an API to bring in stuff from another server, and there's only so many ways that you can do that in the client. HTML was designed for webpages to connect together via links, not all on one page, so many of the ways they work (like much of the web) are hacks. These technologies are old, but their uses as APIs is more recent. It's taken a while to figure out the hacks and for client-side APIs to take off.
Read more: url2png.com
Read more: Google Charts API Docs
Read more: Google Static Maps API | Google Street View Image API
More reading: Google Analytics JS Docs
More reading: Disqus Universal Code Docs
More reading: Facebook Like Button
Example URL: http://search.twitter.com/search.json?q=capitoljs
See also: jQuery .ajax() | Flickr API
...they do it all!
Any APIs that use this crazy nested iframe hack will wrap it up in a client library so that mere mortals like us can use it.
Okay so it might seem like we're kind of stretching the browser to make client-side APIs work. Why do we go through so much trouble, when we could just use our servers? Well, there are a couple reasons.. Don’t need a server - can start prototyping before there’s a server, only bring in when necessary. (That’s why I got into it - didn’t have servers to use at Google) Okay, but even if you have a server... Faster for user- doesn’t have to wait for middleman Results can be cached on the client, making it almost INSTANTANEOUS! The user’s browser does the work, no hits on your server Don’t have to worry about your server going down, only theirs. Avoid issues with rate-limiting (for the most part) particularly on cloud services (i.e. Maps API)
Stuff you could write yourself, but find it easier to let the API do for you.
See also: WebPurify JSON Docs | Profane Game
Chris asked to be respectful, but since I'm not capable of doing that myself, I'll simply ask an API to censor me - the WebPurify API.
See also: Aviary Feather API
See also: SimpleGeo Docs
- Multimedia: Music (SoundCloud?), Video, Photos (Instagram, WebPurify) - Document storage: DropBox - Social Networks: Social networks (mostly FB/Twitter)
See also: Wordnik API | ProgrammableWeb