Aaron Worsham

Stamen is the classic “position player” of the web app industry. They do really great work but are rarely singled out for it. Stamen’s job is to make other companies better. They’re mostly known for those really cool flash data mashups available at Digg Labs

Michal Migurski discussed some of the things they learned from Digg when designing the Labs API. Here are some highlights

• Do dates as UNIX timestamp – There is a deep religious philosophy surrounding this kernel of wisdom, but at its center timestamps are just best practice. If you aren’t a unix acolyte, UNIX timestamps are seconds since Jan 1st 1970 (called epoch in some circles). This arbitrarily decided date format is the universal solvent that cleans up all date messes. Trust us, just use it.
• Stick to core formats like XML & JSON. He also mentioned Serialized PHP and Javascript callbacks which are gaining in popularity
• Unit tests are the single best way to coordinate design and development – One of the stories he told about working with the Digg community was that as designers they had a hard time syncing with the programmers at Digg. Unit Tests were the best way to make sure that what Stamen was designing would work on what Digg was writing in their API. If you don’t know what Unit Tests are, start with the wiki page on it
• Expect your database to change – APIs that need to talk to the database (and really, what API doesn’t) will need to be updated as often as the database changes. DB changes can happen quickly at a client company like Digg who is thinking up new features in the wild. That can make for a tough, moving target to hit.
• If you defer a feature at launch it’ll take forever to get to it – This is more of a truism than any great pearl of wisdom, at least to an experienced developer. Once code “ships” you rarely ever have the luxury to revisit missing pieces. The logic goes that if it wasn’t important enough to hold up the launch, then its likely not important enough to hold up the next launch either. At Digg the missing part is the Writable API I believe, though it was hard to hear near the end of the session

Technorati Tags: web2expo, stamen, api, digg, twitter, B2B

Twitter and Digg Labs (represented by Alex Payne and Michal Migurski, respectively) have some experience with API’s. You could say they are war hardened.

Their talk was a well intentioned, if a bit sanitized, version of the experiences they each had in implementing their Application Programming Interfaces. Alex was first, balancing his short talk with what worked and what did not. Here are some of the highlights;

• Let is grow organically – This makes sense for a startup that doesn’t really expect to be the next big thing, though later on in his talk he contradicted this advice in the what-not-to-do section
• Document – This ones a best practice that is both always mentioned and almost always ignored. API’s though kinda live and die on their documentation.
• Support API community – They used the Google Groups app to build up the community.
  Scale from the API perspective – this is where organic doesn’t work. The deal is that if you don’t take the time to think through issues ahead of time, these issues will bite you in the ass.
• Security issues – If users can think about a way to misuse your api, they will. Twitter users would get around caching schemes, rate limiting schemes and attributes in your data model will leak. Good cross domain not xml policy would help.

What mistakes they made

• Didn’t start with api.twitter.com – Now all the twitter traffic intermingles, both api and http. The separation by domain is a good thing to do up front. This will be happening soon, according to Alex
• Didn’t version API from the get-go – Here they found that growing organiclly meant that versioning wasn’t needed. Now, however, versions for depreciation is really a must have. It will be part of the domain move.
• Didn’t make life easier for flash developers – Applications need visual people to be created. This was an eye-opener. Programmers admitting that they need someone else?? The skills of the Flash Developer, traditionally mocked by the programming elite, is really an important part of API tool design. The community that captures flash programmers will have cool looking tools
• Didn’t automate to make life easier for us – Administrative view of active API customers, stats, and admin views isn’t real sexy code work. But is you go forward with your API without these views of how users are using your api, you’re going to be in the dark when tough questions start being asked of your company.

I will cover the second half of this presentation, Michal’s talk on Digg Labs, in a second post.

Technorati Tags: web2expo, api, digg, twitter, B2B