I’m at the API Strategy and Practice Conference here in Chicago, where Kin Lane and Kirsten Hunter have kicked things off with an “Introduction to APIs” workshop. Despite its title, the talk had value for API developers beyond the absolute beginner level. Although the two did an excellent job of explaining what an API is for someone who doesn’t know, the most valuable elements of the talk for someone who has made and used APIs, but wants to get better at it, were the cornucopia of resources that Kin recommended in his portion of the talk and Kirsten’s in her portion of the talk.

Kin Lane: The APIs You Need to Look At to Get Good At APIs (list curated by me—it was bigger than this):

• SalesForce: Kin points out that the SalesForce API stays consistently ahead of the curve on API tools. It has an excellent developer experience. It has tools that integrate into your IDE. It’s well documented, frequently used, and often updated. It’s a great one for an API learning experience.
• Ebay: Similar to SalesForce, Ebay offers a lot of resources for their API.
• Twitter: Twitter’s super-popular API played a huge role in the company’s universality today. Kin points out that the actual API doesn’t exactly adhere to best practices in several ways: don’t copy it. That said, working with it is a worthwhile crash course, and the Twitter API comes with a valuable piece of documentation—a field guide.
• Stripe: Stripe’s API does things right. It’s well-built and it’s simple. It’s worth a look before building your own API to decide what it might look like.
• MapBox: Kin predicts that this is the future of Google Maps. Built on OpenMaps and home to some really beautiful map functionality, MapBox also offers the developer-focused community that we developers love to work in.

Kin also provides an excellent API educational resource over at apievangelist.com.

Kirsten Hunter: The Process to Make an API That Doesn’t Suck

1. Start with the API. Don’t make excuses why you won’t need one. Build out your data with an API in the first place: you’ll be glad you did.
2. Identify your business value in having an API. Is it to increase market penetration (Netflix)? To increase usage (Twitter)? To make the business’s partners want to stick with you, now that they’ve implemented your API, as opposed to switching partners and having to reprogram things? Is it to monetize the API itself (not usually—unless the API is your main product)?
3. Which of your use cases need to be easy and simple? You don’t want an app making lots of calls to your API lots of times on the page that your users need to see.
4. Consider using a schema to establish what your API will do and how it will do it. Schema modelers make this easy, and often they come with automatic documentation!
5. Establish how the API will behave differently for authenticated vs. authorized users. Who will look at data through each API? Who can modify data through each API?
6. Let the design drive your development. You have your use cases and your schema. Those should drive how your API works. The use cases should remain simple, the schema consistent.
7. Marketing to developers: forget the pictures. Make a toy that they can finish, or a gamified tutorial that they can play. They’ll also want code samples and excellent documentation (preach, woman). They’re not annoying children. They are your partners, and they’re offering you their time to make your API relevant. Respect that.

Kirsten provides a ton of great education on APIs over at her website, princesspolymath.com.