Archive of: api
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
(via Four Short Links)
One of the quickest ways to kill your API is to define the API in your code, instead of coding to its definition
Wherever there were Windows PCs in businesses, there’s now the web. Wherever there were peripherals connected to that PC, there’s a need for a new peripheral… just the same, but with a simple web API. Every time you see a dated PC, only running the back-office because of the peripherals hanging off it, there’s a product opportunity.
If those services don’t trust me enough to give me an RSS feed, why should I trust them with my data?
Jeremy Keith — Battle for the planet of the APIs.
With Flickr you can get out, via the API, every single piece of information you put into the system.
Every photo, in every size, plus the completely untouched original. (which we store for you indefinitely, whether or not you pay us) Every tag, every comment, every note, every people tag, every fave. Also your stats, view counts, and referers.
Not the most recent N, not a subset of the data. All of it.
It’s your data, and you’ve granted us a limited license to use it.
Additionally we provide a moderately competently built API that allows you to access your data at rates roughly 500x faster then the rate that will get you banned from Twitter.
Asking people to accept anything else is sharecropping. It’s a bad deal. Flickr helped pioneer “Web 2.0″, and personal data ownership is a key piece of that vision. Just because the wider public hasn’t caught on yet to all the nuances around data access, data privacy, data ownership, and data fidelity, doesn’t mean you shouldn’t be embarrassed to be failing to deliver a quality product.
Data access, doing it right the Flickr way.