Sage Advice for API Providers

Gabe Wachob writes simply the best advice post I’ve seen from a developer to an API Service Provider. We’ve worked together on a few projects and Gabe’s passion shines through in this one. What struck me is it holds true for any product; the customer (developer) is always right. I also believe it is easy to start off thinking an API implementation will be a simple. It’s not something that you can cut corners on or announce prematurely. The devil as always is in the details.

His post is worth a read even if you aren’t writing and developing API’s. (What’s an API many may ask?). One day all organizations may have API of some sorts. Facebook has been very successful at building their platform as a result of their API. However, the Facebook documentation (very fast moving environment) is at best “so-so” and increasingly requires real specialization by developers. Facebook’s a big enough ecosystem where that can happen. Other organizations won’t be so lucky. More importantly organizations starting out on their API initiatives should think carefully about “noise and hype” versus “collective stories”. Stories sell it, their success sells it, and that has a lot to do with how easy it is.

This summarizes Gabe’s key points. See his full post here:

1. Use Building Blocks: Use the code types that are already out there and remember that it is the service behind your API that distinguishes it.
2. The API is a Product: To deliver it the provider must conform to their published specs. No vaporware. Reference apps are a good way to supplement this documentation.
3. Make Life for the Developer EASY: From documentation to libraries, testing and reporting.
4. Eat your own Dogfood. Basically could your own products run off the API?
5. Monitor API Usage. Plan for growth etc.
6. Send clear messages to the Developer Community. Simply they have a commitment and are putting time in. You are serving the customer.
7. Remember the Legal stuff. Perhaps common sense yet put in the disclaimers.
8. Make it fun and make it personal.

This also reminds me of the post I did on Skype’s Developer Community back in 2005 where I identified 8 key dimensions that drive the success and behaviors necessary to bring an effective developer community to life. (This is illustrative; no attempt to update or comment on Skype today.) In that post I had the following headings.

1. Architecture Evangelism
2. Creative Opportunities
3. User Experience
4. Supportive Team
5. Legal Agreements and Public Policy
6. Business Exchange
7. Value Creation
8. Investors and Peers

These just reinforce to me how “collective” the API effort must be within and across the company. It’s not something to just assign to one person. Plus in a small company if you are going to drive your API how important it is that your main product/service is also your reference app (s).