New MEAP: Irresistible APIs

My new book on Irresistible APIs is in early preview on the Manning Early Access Program, and you can download a sample chapter, purchase the book, and help me to make it the best book possible for API creators.

I spend a lot of time traveling around and teaching people how to make better APIs. The current focus of my talks is Designing Irresistible APIs - I'll be giving this talk (or a version of it) at OSCON, and just presented it at Future Insights Live, as well as doing a webcast to get people excited about OSCON. I've uploaded my slide deck on slideshare but I thought I should make a brief post summarizing the ideas in there. There's a newer one here, and a copy of my API 101 slide deck from APIStrat Chicago.

API Design Process

1. Understand the business value of your API.  Are you trying to drive usage, integrate with partners, attract new users, excite existing users?  Your API is unlikely to directly drive revenue unless it's your main product, so understand what you want to get out of your API before you even start creating it.  Note that partner integration is a very strong business value, but what you want to know here is what would you tell your CEO if you were trapped in an elevator with him and he asked why you have an API.
2. How are you going to measure success?  API usage?  How many people use the API vs. the website (APIs are not as resource intensive and can be automated, helping you to create more solid integrations)?  How many partners are integrated?  Again, this is critical for the design process, and critical for communication to your management team, partners, and developer customers.
3. What use cases are you going to support?  Mobile, website, reporting... note that if you want to support a mobile experience, even for third party developers, you have to somehow support the idea of a single call per screen on the device - otherwise mobile developers will go elsewhere to integrate.
4. Now you can design your API.  Using a schema modeling language like RAML, blueprint or swagger is a great way to visualize what your API looks like.  Extending the syntax to allow for expansion or defining exactly what a developer wants should be decided at this point.  Here's a post that discusses the choices you can make, but remember that you're not making these decisions in an absolute way or in a vacuum, you're honestly trying to meet the needs of your users through the use cases you've identified.  Let go of your desire to have a fully RESTful API if it doesn't serve the needs of your users.  Make the use cases dead simple - if you don't make a usable API, nobody's going to use it.  Yes, this applies even to internal APIs - if your API is difficult you'll be swamped with support requests and faced with a lot of internal strife.  Honor your users and their time and they'll repay you by loving your API and evangelizing for you.
5. Great, you've designed your API and even made it.  Now check and make sure - are those use cases dead simple?  Great!  Now what you need to do is create a fantastic developer experience, from on boarding through all their use of the system.  Create a great developer portal.  Provide small-bite tutorials with example code.  Make the developer experience fun and engaging.  Play with your users!