#GlueCon 2014 Notes: Keynote: API SDKs will ruin your life – John Sheehan, Runscope

Keynote: API SDKs will ruin your life – John Sheehan, Runscope

• Started a company to solve issues around building .Net API clients and SDKs
• Spent a lot of time at Twilio thinking about SDKs and writing about how to build the best ones
• When to IFTTT and started to feel the pain of SDKs, as they had a huge Gemfile to use SDKs for other APIs
• Why do SDKs have a strong draw for providers?
  • They are on the critical path to success for your API
  • But now you have 17 APIs due to every version of every language you want to support (.NET, Java, Ruby, Python, PHP, Node)
  • Then another language comes along and you either figure out the language, or you find a community member to build it
  • Quickly becomes an issue for developers, not a critical path for success
  • Auto-generation or dev communities are not the best solution (ask him later)
  • You must build SDKs…for as many platforms as possible…as native as possible…as well documented as possible
  • SDKs for consumers are great for rapid prototyping, no good HTTP client (SDKs help overcome that), building API clients, hide complexity or bad APIs, uses native APIs (only case he would continue to use an SDK)
• Reasons why SDKs are bad:
  • • 1. APIs versioned separate from SDKs that can cause confusion (v1 API, v2 SDK, API goes to v2, SDK looks compat but isn’t)
    • 2. Often lock to specific versions of platform libraries for JSON parsers, HTTP Client, etc
    • 3. Abstraction hides where problems exist – if something goes wrong, where is the problem (the SDK, over the wire, remote server) so debugging gets tricky