"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.
|1995||Netscape & Sun (RIP)|
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.
...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.
Stuff you could write yourself, but find it easier to let the API do for you.
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.
- Multimedia: Music (SoundCloud?), Video, Photos (Instagram, WebPurify) - Document storage: DropBox - Social Networks: Social networks (mostly FB/Twitter)