web 2.0 expo: design your API to support ...good design

Managed to break out of my 7 weeks back at work, either working-or-sleeping rut and check in at Web 2.0 Expo on Wednesday. Besides setting up meetings with some of my industry peeps who i've been missing and haven't seen the post-baby, post-blonde me, I was able to squeeze in a quick round of the Exhibit Hall and an afternoon session from Michael Migurski of Stamen Design and Alex Payne from Twitter on "Design Your API: Learnings from Twitter and Stamen." Their session was basically aimed at how companies providing platforms to developers can enable good design with accessible languages such as Flash, JSON, PHP, etc. that enable good looking tools.

I've been a big fan of Stamen Design data visualizations in the past - was totally wowed a couple of years ago at the Digg v3 party by their Digg Labs visualizations for looking at popular stories in a simple, informative way. They also designed the Digg API that accepts accepts simple REST requests and offers several response types: XML, JSON, Javascript, and serialized PHP.

Most of their API tips are geared the broadest use case of simple GET calls -- not so applicable to big, complex transactional API platforms, such as eBay Trading Web services. But their presentation has takeaways for anyone involved with platforms - make it easier for third party developers to make their applications look good.

To appeal to the broadest swath of Web app developers and avoid having to invest in a lot of technical support resources, they recommend to avoid SOAP and XML -- "too much overhead".

Two examples Mike used in his preso were: Oakland Crimespotting (I know some friends who could get addicted to this) and how they made data more accessible to users, and Digg Labs and how they made data more accessible to developers via API.

• make your API easy for flash, PHP, JSON, JavaScript and Actionscript developers to use
  
• should just work in a browser
• Key registration is a hassle to be avoided: (avoid the overhead if possible)
• do all of your dates as Unix timestamps
• stick to these core formats: XML, JSON (combo of python and JavaScript in practice, AJAX-friendly, avoid XML parsing issues
  
• serialized PHP, JavaScript callbacks
• Cross-domain XML standard makes things easier for Flash developers
• REST - just web-jargon for Moving Things (GET) instead of Doing Stuff.
• Python: Unit tests are the single best way to coordinate design and development. Expect your database to change.
• Developer Support - delegate so that you can scale your developer community. Give developers who provide support to others additional support in-kind
  

Mike also talked about the emerging standard of OAuth - delegated authentication to make it possible to let people in provisionally and API call rate limiting, but revoke when necessary. Sounds an awful lot like a pared down version of the Authentication & Authorization standard that eBay developers have been using since 2004.

My bandwidth being what it is at the moment, I was not able to make it back to the event for more session, but after talking to several folks during the "hallway track", it sounded like the quality of most sessions was much better than last year. I'll definitely be coming back next year in better form, non-sleep deprived form, when I can make the most of the after hour activities again.

Photos accredited to Scott Beale/Laughing Squid and ana/g.