Many API Providers after accepting the need of giving out SDKs, ponder over what languages should they offer them in? The golden answer for this is as many as you can. Developers today are working with a number of languages and platforms, the diversity when it comes to adoption of new technology is all time high. According to a survey on Programmable web, these are the languages programmers are using the most to consume APIs:
- PHP
- Python
- Ruby
- .NET / C#
- Java
- Perl
- ColdFusion
- Node.js
- ActionScript
Some of these languages may be losing popularity, and new languages are being adopted day by day but the fact still remains that APIs are being consumed in multiple languages and you need to cater the need.
Which again gives birth to the question:
How are you going to create SDKs in all these languages?
While it may seem easy, writing client libraries for an API that you wrote yourself, it’s not so simple. It does not only require hours of redundant labour work but also a number of resources, loads of time and a lot of testing, making SDKs more of a chore. Companies who have the $$$ and resources to build in-house SDKs with language experts are at an advantage, leaving the rest dreaming.
Maintaining SDKs is a whole different story. Even companies with huge API teams struggle to update their SDKs on time. APIs tend to evolve and version over time and with every new update, the SDKs go obsolete. Reflecting these changes across SDKs in multiple languages in a way that does not break things is tough, time-consuming work.
Simple maths reveal that around 83% of the total SDK cost comes from keeping it up to date and bug-free after every API update.