Why API Providers Should Offer SDKs

If your business is providing a website and/or mobile app--or even if a website or mobile app merely drives revenue for your core business--then the speed with which customers adopt that offering is critical to the success of your business. Perhaps you've even enhanced the versatility of your website by offering an API that allows others to leverage its functionality and/or the data it contains. And now you're wondering if you should take this a step further by offering an SDK to make consuming your API easier.

ProgrammableWeb.com’s API directory includes more than 14,000 APIs,  a number that is increasing significantly by the day. It’s not surprising, since APIs have changed the way that business is done and how information is shared on the Web. Indeed, APIs have contributed to the rapid growth of such Web giants as eBay, Google, Twitter and Facebook. Pretty much every major Internet company has APIs.

SDKs--in particular, mobile SDKs--are driving the next wave of Web integration: the means by which mobile applications, Web apps, and things (as in the "Internet of Things") derive value from Web-based resources. An SDK, or software development kit, represents a collection of one or more APIs, programming tools and documentation that enables a programmer to develop applications for a specific software package, software framework, operating system or hardware platform. In order to create applications, developers will often download SDKs and start coding.

Before you start to develop your SDK, you'll have to decide on the platform from which you want your API to be consumed. In other words, which devices, operating systems, languages, and applications are your target users running? If your goal is for your API to be consumed by mobile devices, then it makes some sense for you to focus on iOS and Android (in that order), leaving other mobile platforms like Windows for later. Or maybe you see your API being consumed as part of a back-office workflow (on the server-side). In this case, you might want to focus your attention on server platforms like Python, PHP, Node.js, and other similar languages.

Most of the buzz today is around mobile SDKs, particularly for iOS and Android. There are also Java SDKs, JavaScript SDKs, Python SDKs, hardware-specific embedded SDKs, .NET SDKs, Ruby SDKs, PHP SDKs – there's probably at least one SDK for any language you can think of. It all depends on how (and where) you're trying to extend your platform.

The overall goal of an SDK is to get developers up and running with your solution quickly and easily. For this reason, SDKs typically include programming tools, documentation and example code. It's important to have example code so developers can quickly learn what can be done and the best practices for doing it. Example code should contain comments and descriptions of functions and parameters so developers can learn quickly. Depending the complexity your API, a complete reference application may be a good idea. Thorough and accessible documentation is essential in order to instruct and support developers.  

Benefits of SDKs

Providing an SDK has quite a few benefits, including (but not limited to):

      Accelerating deployment: Everyone wants to move at Internet speed, so the faster you can demonstrate the value of your solution, the better. A well-implemented SDK gets developers up and coding more quickly by putting APIs at their fingertips, along with examples of coding best practices and documentation.

      Ensuring best practices: Beyond simply coding faster, best practices help developers write code that plays well with your service. Passing data, commands and status back and forth may not always be the most intuitive thing, and there are subtle differences among services. Moreover, a poorly coded app that works directly with your API could cause a critical issue that might impact your business, your clients’/partners’ businesses, or both. A good SDK can play a big role in preventing the use of bad or inefficient code--and in reducing its impact on systems. A good SDK can also help ensure the right business rules and practices are in place in all of the apps using your service. Making sure that your customers use your service the right way helps them realize its value while minimizing the risk to the API provider

      Increasing security: Security is a hugely important issue in general, and even more so as applications and services increase their interconnected nature. An SDK can be used to decrease fraudulent use of your service. For example, an SDK can be used to encrypt data or code both on devices and as it crosses networks. An SDK can also enforce security requirements--for example, for storing account information, passwords and transaction processing. And, depending on your industry, you could use your SDK to force compliance with regulations like PCI-DSS and HIPAA.

      Controlling your brand image: You've worked hard to build a good service, and that's reflected in your brand. Don't let others make design decisions for you. Your SDK can be used to control the way that developers integrate your service into their own UIs.

      Learning more about your customers (and their customers): Use your SDK to gather analytics about how users interact with your service within the app they're using. Usage statistics are critical in developing, maintaining and improving your service. A properly designed SDK will help you gather the analytics you need to continuously improve your service.

The Bottom Line

If you look closely at the benefits I've listed above, you'll notice that they work together to accomplish one thing: increase revenue. Understanding how customers use your service so you can improve it will increase sales. Plus, think about what lengthens your sales cycle: Customers won't close a deal until they know your solution works for them.

As your customers integrate your services into their apps faster, your sales cycle will get shorter. Get your customers to market faster, and you'll both reap the rewards. Shorter sales cycles usually mean increased sales and greater revenue. You'll have happy salespeople and a happy CFO.

You might even be able to satisfy requirements for key deals by adding functionality to your SDK without making any changes to the rest of your codebase and infrastructure, which will make your techies happy.

If an SDK could make your sales and development teams happy, then what are you waiting for?

Matt Sarrel has been practicing and writing about information technology and information security for over 20 years. He is Executive Director of Sarrel Group, an editorial services/content marketing, product test lab, and information technology consulting company. He is a Contributing Editor for PCMag.com, Triple-G Editor for Backayard Magazine, and contributor to Infoworld, and numerous other sites and publications. Previously, he was a technical director for PC Magazine Labs. Prior to joining PC Magazine, he served as VP of Engineering and IT Manager at two Internet startups. Earlier, he spent almost 10 years providing IT solutions in HIV-and-TB-related medical research settings at the New Jersey Medical School. Mr. Sarrel has a BA (History) from Cornell University, an MPH (Epidemiology) from Columbia University, and is also a Certified Information Systems Security Professional (CISSP).

Comments

Comments(1)

Samrocksc

Good read: I think a big reason you shouldn't release SDKs is because you give a general perception of limitations.   You give one method of security....and people get comfortable with that method, and it creates a target.

The other reason I don't like the SDK is that is draconian in that encourages early 90s style development practices and it encourages operating system(or platform)centric development.

Let's not make it easier, let's make it more versatile?