Software Development Kits (SDKs) are very common throughout the development landscape. SDKs include tools, libraries, and sample code to help programmers build applications and integrate with third-party software. Most API providers offer SDKs to help support specific programming languages and app development paradigms, making them an integral part of an overall developer support strategy. Below, we'll define what SDKs are, explore sample SDKs, and see how SDKs differ from APIs.
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.
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/lastnamewith a simple reusable function, such as
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
2. Twilio SDKs
4. AWS SDKs
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.
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.
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.
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.