Remember mashups? Mashups were cool.
If you fancy partying like it’s nineteen ninety web 2.0, here’s a growing list of public APIs that return JSON.
Fear and loathing in Houston.
- Humanity will never colonize Mars, never build moon bases, never rearrange the asteroids, never build a sphere around the sun.
- There will never be faster-than-light travel. We will not roam across the galaxy. We will not escape our star.
- Life is probably an entirely unexceptional phenomenon; the universe probably teems with it. We will never make contact. We will never fuck green-skinned alien babes.
- The human race will live and die on this rock, and after we are gone something else will take our place. Maybe it already has, without our even noticing.
- All this is good. This is a good thing.
Science fiction as a means of energising climatic and economic change:
Fiction, and science fiction in particular, can help us imagine many futures, and in particular can help us to direct our imaginations towards the futures we want. Imagining a particular kind of future isn’t just day dreaming: it’s an important and active framing that makes it possible for us to construct a future that approaches that imagined vision. In other words, imagining the future is one way of making that future happen.
But it’s important that these visions are preserved:
It’s very likely that our next Octavia Butler is today writing on WattPad or Tumblr or Facebook. When those servers cease to respond, what will we lose? More than the past is at stake—all our imagined futures are at risk, too.
A useful primer on which combinations of attributes and values work best for which form fields:
Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.
Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.
Visit this site using different browsers on different devices to get a feel for what you can do with web technologies.
Native will always be ahead, but the feature gap is closing impressively fast.
Did you know Google runs a free an open image resizing service?
I did not! This could be quite useful. Seeing as it’s an https endpoint, it could be especially useful on https sites that pull images from http domains (and avoid those mixed-content warnings).
Objects that talk are useful, but objects that tattle aren’t.
Remember Aaron’s dConstruct talk? Well, the Atlantic has more details of his work at the Cooper Hewitt museum in this wide-ranging piece that investigates the role of museums, the value of APIs, and the importance of permanent URLs.
As I was leaving, Cope recounted how, early on, a curator had asked him why the collections website and API existed. Why are you doing this?
His retrospective answer wasn’t about scholarship or data-mining or huge interactive exhibits. It was about the web.
I find this incredibly inspiring.
But under the guise of innovation and progress, companies are stripping away worker protections, pushing down wages, and flouting government regulations. At its core, the sharing economy is a scheme to shift risk from companies to workers, discourage labor organizing, and ensure that capitalists can reap huge profits with low fixed costs.
There’s nothing innovative or new about this business model. Uber is just capitalism, in its most naked form.
I like Matt’s observation here that the simple combination of a barebones data format like HTML delivered over HTTP is a good-enough low-level API for joining up all kinds of internet-connected things.
In the last 60 years, the biggest software platform for interop and integration – for new products, services, businesses, and value creation – has not been Android, or iOS, or Windows, or the PDP-11. The biggest and best platform has been the web.
One implication is that successful products are not necessarily those with seamless, beautiful, tightly-controlled “experiences”, but rather the ones that are capable of talking to each other.
Small things, loosely joined.
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.