In our last couple API strategy workshops, we've had good discussions on a common question for API providers - do you need to offer an SDK (software dev kit) for your API?
In this context we defined an SDK as going beyond offering an API to include platform-specific code that developers use in their apps to invoke API operations, also including the source code, and documentation that developers might need. Here's what we came up with:
Reasons to consider an SDK:
Speed adoption on a specific platform - for example Objective C SDK for iPhone. Lots of experienced developers are just starting off with objective C+ so an SDK might be helpful.
Simplify integration effort required to work with your API - If key use cases are complex or need to be complemented by standard on-client processing.
An SDK can help reduce bad or inefficent code that might slow down service for everyone.
To market your API to a specific community - you upload the SDK to a samples or plug-in page on the platform's exisitng developer community.
Reasons you might not need an SDK:
If your API is designed for adoption - standards-based, well documented, etc.. developers may be able to get rolling without a client SDK.
Resources - it's tough to do a SDK for each platform you target, you'll have to pick carefully. Also, it can be time consuming and expensive to create SDKs (tip: maybe packaging up internal samples or test cycles can kickstart things)
Maintenance and versioning - convincing clients to upgrade to the newest version can be rough. Also, capturing the "local flavor" of each language you support can be a challenge.
Complexity -On each platform there might be use cases you don't expect, like keeping application-level secrets off clients, debugging, etc.
Agree or disagree?