Over the last couple of months, I’ve had many great opportunities to road test my findings on SDKs vs. APIs, with a wide variety of audiences – at our API Academy Summits in New York and London, on tour with the Nordic APIs team in Stockholm and Copenhagen and at my most recent API Workshop in Istanbul. Given the apparent relevance of the topic and the lively discussions I’ve had around it, I’d like to take this opportunity to summarize some of the insights and recommendations that have come up.
If you’ve been following our blog, you will remember that I started this topic with the observation that leveraging an API increasingly seems to involve using an SDK rather than the API itself. I followed up with a post talking about my decidedly mixed experiences of trying to use SDKs. My own experiences inspired the headline of this post: SDKs work until they don’t.
So, what are the main motivations to invest in an SDK, from an API-provider perspective?
- Simplifying API design by extracting business logic into the client
- Maximizing scalability by exploiting client-side processing
- Empowering developers to leverage the API more quickly
- Presenting an optimized client from a target-platform perspective (e.g. for mobile connectivity or constrained hardware)
- Providing a strongly-typed presentation of the API in a variety of programming languages
Let’s contrast all this with the main drawbacks of SDKs:
- Picking which platforms, languages and frameworks to support – some of your target developers are going to end up disappointed
- Relying on third-party frameworks – any developer who has to integrate with two or more APIs leveraging the same framework at different version levels is bound to experience some headaches, for example
- Adding carry-on weight of unused functionality to the application
- Incurring long-term support costs for the SDK
But to me, the biggest risk of a SDK-first approach lies in making API design an afterthought. We have come to this point in the API evolution because pragmatic REST introduces just enough constraints to force us to think about how we can abstract the underlying business asset into a resource-based model restricted to CRUD-style interactions. An SDK-first approach might tempt us to go back to a RPC-style API design mirroring the backend implementation, resulting in all the inherent integration complexities we had with Web services.
So, if and when you decide on a SDK, keep the above in mind. You might still come to the conclusion that you need an SDK in order to quickly onboard developers or provide the best client for your API but at least you will be able to consciously weigh the benefits against the drawbacks.
If you want to dig more deeply into the subject, I can highly recommend the following podcasts, articles and blog posts, which helped greatly in forming my own opinions:
- Traffic & Weather Podcast Episode 18
- Traffic & Weather Podcast Episode 20
- Why I Don’t Want Your SDK in Production
- Why No One Wants to Use Your API
- Why SDKs are Better Than APIs
- Panel Urges API Providers to Prioritize Their Developer Experiences
- Will Internet of Things & the SDK Push Out REST?