Not all API providers know how to make developers happy. In fact, although there are now over 1,100 web service APIs available, many of those API providers fail to really understand the needs and motivations of their (potential) developer community. For evidence of how developers can react to both well-run and badly-run API programs, look no further than a very insightful blog post from mashup developer Alexander Lucas on Making Your Webservice More Developer Friendly (Alex is the creator of Migratr a useful desktop mashup that uses APIs from 11 different web services in order to let you migrate photos between different online photo services).In his detailed post he gives what’s clearly real-world, from-the-trenches feedback (and wit) from an experienced mashup developer on what works and what doesn’t: I’ve been working on Migratr for around a year and a half now, and in that time have added support for 11 different webservices. Sometimes I’ve grabbed third party libraries designed for interacting with those API’s, other times I coded up the service-interaction layer myself, and I’ve gone through SOAP, Rest (via URL munging or XML via post), JSON and in one case, even webscraping. It’s been an immensely educational and rewarding experience, with degrees of difficulty varying from totally easy (23HQ, by copying the flickr API verbatim and changing only URL endpoints, took about an hour including testing) to ridiculously difficult (AOL Pictures might have been more popular if their API was more than lipservice). I can only speak to Photo-related web services, as that would be the area where I have the most experience. But I think most web services “get it” with regards to an API- By publishing an API, and enabling and encouraging developers to interact with your webservice, you’ve effectively given yourself a dev team larger than you could ever hope to afford. Users passionate about your services, with ideas on how to extend and improve it, and the know-how to implement those great ideas. More applications related to your website means more ways for users to interact with it, which means more chance of a “killer feature” written by a user of your service that ends up driving thousands of new users to you, any one of which can be a developer that continues the cycle. It’s an upward spiral. But it takes more than just publishing an API. You have to make your developers WANT to write stuff for your service. Make it easy and enjoyable for them, and remove as many roadblocks and speedbumps as you possibly can so that they can complete their brilliant idea before throwing up their hands in frustration, or slowly, quietly losing motivation amidst a sea of vicious bugs, counter-intuitive behavior and documentation that either looks like it was written by Hemingway or run through babelfish. He then goes on to provide an on-the-money “checklist for being developer-friendly”:
