This tool for building ScrAPIs is an interesting development—the current trend for not providing a simple API (or even a simple RSS feed) is being interpreted as damage and routed around.
I agree completely with the sentiment of this article (although the title is perhaps a bit overblown): you shouldn’t need a separate API—that’s what you’re existing URL structure should be.
I’m not entirely sure that content negotiation is the best way to go when it comes to serving up different representations: there’s a real value in being able to paste a URL into a browser window to get back a JSON or XML representation of a resource.
But this is spot-on about the ludicrous over-engineered complexity of most APIs. It’s ridiculous that I can enter a URL into a browser window to get an HTML representation of my latest tweets, but I have to sign up for an API key and jump through OAuth hoops, and agree to display the results in a specific way if I want to get a JSON representation of the same content. Ludicrous!
The authors of the Extensible Web Manifesto explain the thinking behind their …uh… thinking.
A terrific lighting talk by Scott on the need to think bigger. The solution to long-term issues is rarely “start a company”—we need to think more about creating a shared infrastructure …just like the internet.
A superb piece by Marco Arment prompted by the closing of Google Reader. He nails the power of RSS:
RSS represents the antithesis of this new world: it’s completely open, decentralized, and owned by nobody, just like the web itself. It allows anyone, large or small, to build something new and disrupt anyone else they’d like because nobody has to fly six salespeople out first to work out a partnership with anyone else’s salespeople.
And he’s absolutely on the money when he describes what changed:
RSS, semantic markup, microformats, and open APIs all enable interoperability, but the big players don’t want that — they want to lock you in, shut out competitors, and make a service so proprietary that even if you could get your data out, it would be either useless (no alternatives to import into) or cripplingly lonely (empty social networks).
I share his anger.
Well, fuck them, and fuck that.
Oh, no! How horrid! Now Twitter won’t control the “user experience” of that widget!
Instead, the person who actually posted the tweets in the first place gets to decide how they should be displayed. Crazy idea, isn’t it?
Design principles for APIs.
An API is a user interface for developers. Put the effort in to ensure it’s not just functional but pleasant to use.
A comprehensive look at the current state of things in the world of responsive design, with a look to possible future APIs.
I need to get Matt to an Indie Web Camp.
Charles Arthur analyses the data from Google’s woeful history of shutting down its services.
So if you want to know when Google Keep, opened for business on 21 March 2013, will probably shut - again, assuming Google decides it’s just not working - then, the mean suggests the answer is: 18 March 2017. That’s about long enough for you to cram lots of information that you might rely on into it; and also long enough for Google to discover that, well, people aren’t using it to the extent that it hoped.
VC funding that actually makes sense, from the always-sensible Maciej Cegłowski.
Oh, my! This excellent, excellent post from Anil Dash is a great summation of what has changed on the web, and how many of today’s big-name services are no longer imbued with the spirit of the web.
Either you remember how things used to be and you’ll nod your head vigorously in recognition and agreement …or you’re too young to remember this, and you won’t quite believe that is how things worked.
This isn’t some standard polemic about “those stupid walled-garden networks are bad!” I know that Facebook and Twitter and Pinterest and LinkedIn and the rest are great sites, and they give their users a lot of value. They’re amazing achievements, from a pure software perspective. But they’re based on a few assumptions that aren’t necessarily correct. The primary fallacy that underpins many of their mistakes is that user flexibility and control necessarily lead to a user experience complexity that hurts growth. And the second, more grave fallacy, is the thinking that exerting extreme control over users is the best way to maximize the profitability and sustainability of their networks.
The best “Mobile First” strategy is an “API First” strategy:
“Mobile first” companies really are just a front end selection accessing a solid API driven backend infrastructure.
I think Luke would agree. He built a command line interface for Bagcheck, for example, before there was even a UI—mobile or otherwise.
A handy step-by-step guide to scraping HTML to get data out. Useful for services (—cough—Twitter—cough—) that keep changing the rules of their API use.
A thoroughly addictive use of the Instagram API (along with Node.js and Socket.io): see a montage of images being taken in a city right now.
The video of the panel I moderated on device and network APIs on the second day of Mobilism in Amsterdam. It’s not quite as snappy as the browser panel (which, given the subject matter, is unsurprising) but it was still good fun.
Glenn gives a rational thoughtful explanation of why he’s as pissed off as I am about Google’s destruction of the Social Graph API.
Google are shutting down the Social Graph API. Twunts.
Brent Simmons follows up on that Dave Winer post with some future-friendly thoughts:
If I had to choose one or the other — if I had some crazy power but I had to wipe out either native apps or web apps — I’d wipe out native apps. (While somehow excluding browsers, text editors, outliners, web servers, and all those apps we need to make web apps.)
That’s not the case, though. Nothing has to get wiped out.
Mobile HTML5 - compatibility tables for iPhone, Android, BlackBerry, Symbian, iPad and other mobile devices
This just launched at the Breaking Development conference: another site that uses the term HTML5 to include CSS and Ajax. Still, despite its inaccurate nomenclature, it’s a useful compatibility table of device support in mobile browsers.
This is a fascinating take on progressive enhancement from Luke: for a service-based site, the equivalent of Content First is API first …literally a command line interface as a baseline.
This intrigues me. “If this, then that” sounds like a good approach to loosely joining some small pieces.
This could be an interesting tool for building a voice or SMS interface onto Huffduffer.
An excellent little service: give it your Last.fm username and it finds music blogs you’ll probably like. I’ve found a treasure trove of Huffduffer sources through this.
An interesting, if necessarily somewhat complicated-looking, API from Google: analyse your user's past behaviour to predict future outcomes.
It's down for me right now, but this API from Qwerly looks like a great addition to complement Google's Social Graph API — it finds rel="me" links from a Twitter username.
A great write-up of the latest additions to the Guardian's Open Platform API including a lukewarm assessment of Semantic Web technologies like RDF.
An inspiring presentation by Tom Armitage on the value of open data.
A very handy looking API that turns file uploading (and conversion) into a service.
A handy interface onto The Guardian's new API.
Kellan outlines the bare minimum you should expect from any service that you are putting data into.
An API for Turing test questions.
An excellent way to do geolocation even in browser that don't support it natively.
A cute hardware hack: send a tweet with the word TwitweeClock, the hashtag #TwitweeClock, or the username @TwitweeClock, and this cuckoo clock will, well, cuckoo.
Some Ruby on Rails code for enhancing sign-up forms using Google's Social Graph API, inspired by Huffduffer.
The V&A has an API. Who knew? Looks very nice indeed.
A handy RESTful interface for retrieving favicons as images.
Since Amazon decided to require signed requests for its API, I'm going to have to use this code to keep Huffduffer and The Session working. Grrrr... cool APIs don't change.
Good news, everyone. Yahoo aren't shutting down the term extractor API. Happy developer is happy. Now if only they save GeoCities...
Crap. The very powerful term extractor API from Yahoo is being closed down. Sad developer is sad.
Get Creative Commons stickers at the click of a button thanks to Brian and the Moo API.
A nice overview of Glenn's XFN Firefox plug-in.
A person-specific portal generated using Google's Social Graph API. And it's less than 5K!
Trust Tom to use the Guardian's new API for the purpose of answering those pressing questions, like "is fuckknuckle *really* the new cockbadger?"
A beautiful use of the Flickr API that allows you to browse photos with a colour picker.
The Guardian has released a shedload of data for us to play with. Go forth and hack.
The “blind astrometry server” is a program which monitors the Astrometry group on Flickr, looking for new photos of the night sky. It then analyzes each photo, and from the unique star positions shown it figures out what part of the sky was photographed and what interesting planets, galaxies or nebulae are contained within.
A set of APIs built on top of OpenStreetMap data.
Vint Cerf announces M-Lab: an excellent resource which will allow people to find out if and how their internet access is being throttled. Viva l'internet!
A nice way to play around with Google's APIs. Example code is provided which you can edit and immediately see the results.
A little Twitter app from Christian ...that doesn't ask for your password.
Yahoo's RESTful query language can now parse microformats. This is excellent news ...although I'm personally finding it tough to wrap my head around the documentation. It's certainly trickier than hKit but then, it's almost certainly more powerful too.
A super-simple lightweight PHP class by Kellan for calling the Flickr API and receiving back an array of results.
The first ever Last.fm hack day is taking place in London on December 14th. I'll be there.
The last project from Simon and Nat is essentially a way of viewing groups (slices of activity) on Twitter ...and it exposes a security flaw in the JSON-P API too.
Here's a nifty little mashup from Simon: create Moo cards with book details from Amazon.
This new Flickr API method makes it really easy to get a list of visited places for a Flickr user.
Thanks to Brian and the Moo API, you can know print your own microformats stickers.
The Google Chart API can produce QR codes. Neato!
Tell the UK government what you'd build with public information and they could help fund your idea. Time to put your hacking hat on.
All of Google's data APIs (Calendar, Blogger, Contacts, etc.) all now support OAuth. Excellent!
Christian is using the prize money he won at Mashed to put on an event in London in September devoted to "ethical hacking": creating mashups to make social networks more accessible.
You can know use an API (with BBAuth) to get contact Yahoo account contact details. There really is no excuse now for still using the password anti-pattern.
Last.fm have gathered together the best apps built on their API and put them all in one handy browsable spot.
The Olinda has arrived. I love the physical API.
The Pownce API, like Flickr, can now return response in LOLspeak should you so wish.
As promised by Kevin Marks in the Q&A after my panel at South by Southwest, the Google Contacts API now supports OAuth. w00t!
David Recordon shares his first impressions of Google App Engine.
Gareth is putting some wisdom of crowds behind the design of APIs. Vote on the principles that you think are important in a good API.
If anybody out there has some experience with the Amazon Associates Web Service API and XSLT, I could do with some help.
Now this is how to do the "find your friends" trick. For GMail, Yahoo Mail, and Hotmail, Flickr never once asks for your password. Bravo!
This is great news! Brad Fitzpatrick and Kevin Marks have built a new Google API that will spider XFN links.
A "barnacle app" that pulls out all the overheard quotes from Twitter.
All the code you need to add charts and graphs to your site.
I had a chat with Paul Boag this morning and now the podcast episode is online. Me, Paul Hammond, Drew McLellan and Christian Heilmann discuss APIs.
This is good news. You can expect Gravatar service to get faster and better.
A new feature on Matthew Somerville's brilliant train timetable site. Just put /fares at the end of any URL to get the cheapest available fare.
Dopplr can has API.
The second part of Gareth's series for Digital Web on APIs. This time he's got some PHP code samples for parsing XML and JSON.
PayPal has a new competitor. Amazon is now offering a payment services to developers.
Find out whether you really need a car in your neighbourhood. My place got a score of 75 which is pretty darn good.
I'm loving this mashup of lolcats, Twitter and Flickr. Occasionally the text and the picture matches up in a serendipitously hilarious way.
This is a brilliant idea by Aaron: printing QOOP books of Flickr pics where each picture is accompanied by a map. It's all about the context, baby!
Multimap's API is now open and free as in beer (as long as the traffic is within reasonable bounds). This is good stuff. And they're all in with the Open Street Map guys too.
Track Cindy and Jason on their trip across the country... mashup style.
Registration for Hack Day Europe (June 16th-17th) is open. Sign up now! This is going to be a lot of fun.
Google Developer Day will be taking place around the globe on May 31st, including a London event. I'll probably be in Copenhagen though.
Google gets behind GeoRSS. This is good. Somewhere, Mikel Maron is doing a little dance.
Another fun toy that uses Twitter's API, this one from Richard Pope.
A mesmerising mashup of Twitter and Google Maps. I could watch this all day.
Aral just posted his extensions to the Twitter API.
A nice collection of royalty free texture photos using the Flickr API.