Client-side APIs
How, What, & Why
APIs are Awesome
Earlier, Alex talked about third party javascript and how you can be a provider (and not screw up the people using you).
Now I want to talk about the inverse - being a user of third party javascript - or what I call APIs - because I bet
most of you are making websites that use atleast one API, if not more.
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.
Then: Server-side APIs
When I was a kid ...
When I was a kid, APIs were only things you accessed from the server, like your PHP or Python script, typically returning XML. SOAP/Dad.
Most APIs were also SOAP and XML-based. My dad was a fan, I was not. So I didn't really use APIs then, or talk to my dad.
Now: Client-side APIs!
But nowadays, APIs take many forms and many of them can be directly used from the client,
without the use of a server.
Server side APIs all work pretty much the same, but client side APIs use a few different techniques.
Alex touched on them in his talk, so let's just recap.
Client-side APIs: How?
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.
IMG as API
First image API?
IMG as API: url2png
IMG as API: Google Charts API
IMG as API: Google Maps Image APIs
EMBED/OBJECT as API
Flickr Slideshow:
IFRAME as API: Simple
Vimeo Embed:
XmlHttpRequest as API?
SCRIPT as API: Libraries
Your code:
Their code:
But without data, it's not that exciting. Luckily theres a way.
SCRIPT as API: Data (JSONP)
Your page:
API Server:
JSONP: Flickr API
IFRAME + postMessage as API
Your page:
The API:
IFRAME API: Facebook
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.
XmlHttpRequest + CORS = API!
API Server:
XMLHR + CORS as API: Bitly
XML + CORS: Support
| Mozilla Firefox | 3.5+
|
| Google Chrome | 3+
|
| Apple Safari | 4+
|
| Internet Explorer | 8+
|
| Opera | None
|
Client-side APIs: Stats
API Formats:
IMG | ~10s
|
SCRIPT(JSONP) | ~100s
|
OBJECT/EMBED | ~10s
|
XMLHttpRequest(+CORS) | ~10s
|
JSONP APIs:
Of these technologies, the most common by far is JSONP,
so that's the one you really want to understand well right now.
And as you can see from this graph, it's growing at more than a linear rate.
CORS is the future of APIs, but popular adoption is probably
still a few years off.
Many APIs use a combination of these technologies - like the Maps API.
Client-side APIs: Why?
- No server necessary
- Faster for user
- Less cost
- Less failure points
- Less limits
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)
Client-side APIs: What?
Client-side APIs: What?
Client-side APIs: Functionality
- Analytics
- Site Search
- Text Processing (Translation/Analysis/TTS/Conversion)
- Image Processing (Editing/Filter)
- Payment
- Communication (Telephony/Messaging/Chat/Email)
Stuff you could write yourself, but find it easier to let the API do for you.
Text Processing: WebPurify
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.
Image Processing: Aviary
Client-side APIs: Data
- Mapping
- Real Estate
- Shopping
- Weather
- Movies
- Science
- Books
- Words
- Government
- Food
- Sports
- Travel
- Wikipedia (Everything)
APIs: User Data
- Social Networks
- Multimedia: Music, Video, Photos
- Documents
- Multimedia: Music (SoundCloud?), Video, Photos (Instagram, WebPurify)
- Document storage: DropBox
- Social Networks: Social networks (mostly FB/Twitter)
So you want to use an API...
- Will you save time/money?
- What are the terms?
- What is the pricing?
- How stable is it?
- How will it affect performance?
- What's your plan B?
APIs are...