What is an SDK?

SDK stands for Software Development Kit. An SDK is a toolkit that helps developers create applications, add new functionality, or make integrations. These specialty packages vary by form and function in each case but are typically downloadable and conform to a particular language or platform, offering reusable code components to make engineering tasks simpler.

SDKs may be platform-specific, such as supporting native mobile experiences (Android SDK, iOS SDK, Windows SDKs) or web-based frameworks (JavaScript, React Native, Flutter). Many SDKs are also language-specific, offering support for programming languages such as C#, Java, Node.js, PHP, Python, Ruby, Go, and others. These are often referred to as server-side SDKs or code libraries. API-first Software-as-a-Service companies regularly deploy SDKs to improve the integration developer experience.

So, what is in an SDK? An SDK may be comprised of code, knowledge, and interactive capabilities:

• Helper code libraries and reusable methods
• Reference documentation
• Set-up and authentication instructions
• Code samples, sample projects, or project templates
• Virtual testing environments or sandboxes
• Command-Line Interface (CLI) utilities
• UI design components
• Additional support materials

What's the difference between an SDK and an API?

Another common confusion is the difference between an SDK and an API. So, let's break the two down.

Firstly, an Application Programming Interface (API) enables communication between systems. An API is structured as a set of methods and parameters. By calling these methods, an application can integrate data and functionality in a reusable way. System APIs have been intrinsic to software development since the dawn of the PC, enabling libraries to act as shared interfaces. However, today when we discuss APIs, we typically refer to web-based APIs that follow REST design style and serve clients over HTTP. These lightweight, straightforward, client-agnostic functional interfaces have become a standard method for networked machine-to-machine communication — some are even products in their own right. Nevertheless, APIs are indeed still used internally, such as within a device's operating system.

Whereas API integration requires specific integration expertise, SDKs, on the other hand, are more intuitive. They meet developers where they are. APIs often require authentication schemes, complex headers, HTTP methods, and other nuances. An SDK could abstract this complexity, replacing clunky code to call something like api.com/V1/customer/lastname with a simple reusable function, such as storeSDK.getCustomer.lastname.

SDKs are also technically distinct. Whereas web APIs serve data over a network, SDKs are downloaded and more integrated within the local development environment. Whereas REST APIs are platform-agnostic, SDKs make services gnostic, catering to specific languages and platforms. SDKs are more like an abstraction layer to an API, including more robust faculties. Of course, not all SDKs include API access — some do not deal with networking and focus solely on local processing. On that note, some APIs are even shipped within SDKs.

Five examples of SDKs

To help better understand SDKs and their relationship to APIs, let's look at some examples.

1. Stripe SDKs

Stripe, the popular online payment processing platform, provides multiple SDKs to integrate its services, acting as wrappers to the core Stripe APIs. For example, Stripe iOS SDK, and the Stripe Android SDK appeal to mobile developers. Stripe also provides a browser-side JavaScript SDK, Stripe.js, as well as other client libraries for Ruby, Python, PHP, Java, Node.js, Go, and .NET. Unofficial community libraries help extend Stripe services into more niche environments, like Angular, Elixir, and Flutter.

2. Twilio SDKs

Twilio, the well-known API-first service for text, chat, voice, and video, provides many extensions beyond its core REST APIs. Like Stripe, Twilo separates its SDKs by function, offering an iOS SDK, Android SDK, and JavaScript library per service. For example, the Twilio Programmable Voice SDK for Android can be used to program Voice-over-IP (VoIP) into native Android applications.

3. Shopify Storefront API SDKs

Shopify is a framework for eCommerce, offering programmable utilities to get an online store up and running. Shopify exposes its platform through its APIs, which are made more accessible via SDKs and code libraries. For example, the Shopify Storefront API helps build customer-facing shopping and checkout experiences. Since online shopping is ubiquitous across user environments, SDKs help match the look and feel of native applications. The Shopify Storefront API SDKs include Android, iOS, a JavaScript Buy SDK for websites, and even a Unitiy Buy SDK for video games.

4. AWS SDKs

Amazon Web Services (AWS) provides many SDKs to support its vast tooling landscape. AWS language-specific SDKs help engineers call AWS services using the idioms of their preferred language. These include JavaScript, Python, PHP, .NET, Ruby. Java, Go, Node.js, and C++. For example, boto, the Python interface to AWS, can be installed from a CLI using pip install boto3. Using AWS SDKs, engineers can initiate AWS services such as cloud computing, content delivery, monitoring, authentication, cloud storage, and other functions from within their applications.

5. Square SDKs

Square, the popular payments processor, provides SDKs to ease API integration. Square supports SDKs in Java, .NET, NodeJS, PHP, Python, and Ruby programming languages. Since Square incorporates reader devices for in-person sales, it also provides mobile SDKs that focus on this feature. One interesting part of Square SDKs is that they come pre-packaged with an isolated server, so consumers can easily test API calls on non-production endpoints and view responses. Also, Square offers an online API Explorer to generate API requests in various languages — a model for easy developer experience and API onboarding.

These commonly-used examples only scratch the surface of the many SDKs in use today. Google Cloud SDK, Twitter Fabric, and the Twitch SDK are other examples. Most major technology companies provide SDKs to interact with their API-driven services. In fact, ProgrammableWeb tracks over 19,000 public SDKs — that's nearly one SDK for every public API in existence!

Generating and maintaining SDKs

Though there are undoubtedly many SDKs on the market, don't assume it's easy to build one. There are many hurdles in developing and maintaining SDKs that both developer users and API providers should be aware of.

Inconsistencies between API documentation and production are typical — see Hyrum's Law. These errors can become amplified with an SDK abstraction layer since support engineers must upkeep SDKs with new API versions and mobile OS changes and new programming language iterations.

To set the context, consider three common ways API providers typically construct their SDKs:

• Community Libraries: One option is to simply not support official SDKs and rely on open-source community projects, like the OpenWeather JS SDK. While time and effort are reduced, quality assurance may suffer under a loss of control.
• Manually-Crafted SDKs: The next option is to build SDKs from scratch. Though this grants an API provider ultimate control, there is a limit on how many you can feasibility support. Small-to-medium-sized groups may not possess field experts and thus must choose which scenarios to support wisely.
• Auto-Generated SDKs: The last option is to auto-generate SDKs. This can be accomplished using a standard API specification, such as OpenAPI, and a utility like OpenAPI Generator, which can generate clients, servers, and documentation from OpenAPI 2.0/3.x documents. Another tool is Swagger Codegen, which can generate server stubs and client SDKs from any OpenAPI definition.
• SDK-as-a-service: Recently, there has been a rise in the popularity of commercial SDK-as-a-Service providers such as Speakeasy, Stainless, LibLab, Fern, API Matic, and Konfig.

Among these strategies, auto-generation is becoming more popular among API-first companies who want to support a growing number of programming preferences. This is largely thanks to the advent of OpenAPI, a standard specification that can act as a single source of truth for API descriptions. As long as OpenAPI Definitions are stable, the onus shifts to code generators to produce viable support materials.

Client-side vs server-side SDKs

The differences between client- and server-side SDKs helps you determine which type of SDK to integrate depending on the programming language and framework inside your stack.

Client-side SDKs

These are SDKs intended to be used in a non-trusted environment, such as a web browser or mobile device. This also includes mobile SDKs.

Popular client libraries; JavaScript, Typescript, Android, React, and many more.

Server-side SDKs

These SDKs are used in a trusted environment where you keep API keys and secrets safe, such as inside a web server.

Popular server-side SDKs; Node.js, C++, PHP, Python, and many more.

Benefits of providing an SDK

Though maintenance poses some hurdles, there are clear benefits to providing an SDK. In today's mix of platforms, clients, and hybrid deployments, API providers can use SDKs to appeal to specific coding preferences, making integration much easier for individual developers.

By supporting multiple programming languages, an API-as-product opens its reach to more potential engineers, thus increasing the business's total addressable market. iOS and Android SDKs also benefit from reproducing more native-feeling characteristics within mobile applications, thus polishing the end-user interaction.

Ultimately, SDKs improve the developer experience by meeting engineers in their comfort zone. It will be interesting to follow how SDKs and code libraries continue to evolve around API services, especially as standard specifications and powerful open-source tools increase accessibility for more problem solvers.