A software developer will rarely get excited about the idea of writing everything from scratch when creating a website or new application. And, with multiple tools to create software applications with complex functionality already out there, there’s often no need to do so.
Using external services or products that already exist can be a great way to save time and reduce costs in the development process, with a final product that’s just as – if not more – robust than if every element of it had been created from the ground up.
APIs and SDKs are two acronyms that are common examples of such tools that might be used by a developer. Software newbies might, however, be confused about which of these development tools is right for the job at hand. And, in fact, sometimes the answer is both.
But before we get to making that decision, let’s look more closely at what application programming interfaces (more and more of which are RESTful – defined below – in 2021) and software development kits actually are, how they differ, and what you can use each one for.
An Application Programming Interface, commonly known as an API, is a product that enables information to flow between two or more pieces of software.
Standardizing information in this way, without needing to know all the ins and outs of the software providing the desired service, allows products to “talk” to each other in a language they can both understand.
Sending commands, and/or receiving information, to a piece of third party software allows you to use its services as building blocks in your own offerings.
Operating systems, web servers, database servers, and any kind of software for that matter, can offer application programming interfaces for people to interact with. The popularity of APIs has exploded in recent years thanks to mass adoption of smart home automation.
When programming applications or writing software, developers can use APIs to interact with a database, send requests over the web, encrypt data, generate random numbers and so on.
To return to the example of home automation, programmers have even used food delivery APIs and smart bulbs to switch on the porch lights automatically as their pizza is arriving!
Use cases for application programming interfaces are incredibly diverse because they can be used to do...well, just about anything. For example, Windows systems contain sets of DLLs (dynamic link libraries) that provide access to OS elements – windows, network – and to the system – memory, display – via APIs.
Plus, there are remote application programming interfaces that reside on another machine and can be used via a protocol, e.g. ICMP to access APIs on Cisco routers.
The most common APIs of all are web APIs, which are accessible via HTTP. They’re what we specialise in here at Abstract, with a catalogue of APIs – from email validation and image processing through to translation and web scraping – that has literally thousands of use cases.
Web-based application programming interfaces can be used to push or pull (or both) data. For example, one could be used to retrieve data about the exchange rate between two different currencies or “called” to take an action, such as ordering a service or product.
The best APIs offer additional information that’s designed to help with implementation for developers. A portal containing extensive documentation, use cases and information about versioning is one example of this.
Under the umbrella of application programming interfaces, there are a few main API types including:
Public APIs are accessible without restrictions, which often means no need for prior registration, an API key, or authorization. The Wikipedia API, which allows the retrieval of information on pages or categories, is a nice example of a public application programming interface. With this type of API, free access is very common.
Private APIs, as the name suggests, are not readily available to members of the general public. They allow parts of the same software to communicate with each other behind the scenes. Netflix, for example, is known for its microservice architecture and uses web application programming interfaces to connect different elements of its apps.
Commercial application programming interfaces are similar to public APIs, but have some key restrictions associated with them. They might be used to allow a provider's customers to access data (e.g. Abstract) or a paid service. API products like these are used by Amazon, allowing people to place orders away from their main site.
A software development kit, or an SDK, is a set of tools – e.g. code editor, compiler, debugger, documentation etc. – that enables developers to build applications for a particular software framework or system.
Two popular examples of software development kits include the Java SDK and Android devkit for mobile apps. The latter of these includes phone control drivers, network protocols, code libraries and APIs in addition to the tools listed above, so people can make software for Android systems.
Like with application programming interfaces, some SDKs are free and others are paid.
Why would someone make their software development kit free? The simple answer is that companies do this to attract developers to use their SDK. Take Android, for example...
Even though Android has been around (slightly!) longer than Apple, they face stiff competition from the iPhone and Apple’s associated iOS SDK. By making their software development kit free, which Apple’s is too, Android encourages the development of games and apps designed for their platform.
If you’re adding one specific feature to a piece of software, and there’s an API connection that can help you accomplish that, you might want to use that API. If you need a toolset to develop software for a specific platform or hardware, you’ll probably be looking for a software development kit designed for it.
Using an SDK provides all of the documentation etc. you need to understand – and build a product that’s optimized for – that particular platform. On the other hand, you don’t really need to know how a service works or how it’s built internally when you’re using an application programming interface. As long as it does what you tell it to, that is!
It’s also worth noting that you’ll generally retain ownership and control over a tool or product created using an software development kit while using an API is akin to, to use an old expression, building your house on someone else’s land.
If the application programming interface provider experiences downtime or decides to up their prices, you don’t have any control over that. That certainly doesn’t mean you should disregard APIs, because they’re invaluable if you’re looking for a specific functionality, just that you’ll want to research an API’s reliability before you start building anything with it.
Just in case you’re still not quite getting it, let’s take a look at a practical example.
You’re going from A to B and decide to take your car. That car is a full environment for personal transportation in that it includes a steering wheel, pedals, an engine, gears, and everything else you need to move around. The car can be thought of as a software development kit by the end-user, i.e. the driver.
Now, let’s say that your brother wants to take a shortcut over some fields; he’s always been a bit of a rebel, that one. Because he’s taking the road less travelled, he fires up his dirtbike. That’s an SDK too, but one targeted at a completely different environment...or OS, if you will.
Back in your car, you’re not quite sure of the route you need to take. You get out your GPS and enter the destination address. The GPS is an application programming interface, and queries satellites to figure out where you need to go. Some cars have built-in GPS, which is a neat analogy for the fact that many SDKs contain and provide APIs.
As you might already have figured out from the above, the need to choose between an API and an SDK is dictated more by what you’re trying to achieve than anything else. And using one doesn’t necessarily mean that you won’t be able to use the other.
It’s not unusual for software development kits to contain APIs, and it’s always possible to use third party API calls to add additional functionality to your software if necessary. Remote APIs, for example, are compatible with just about any software because communication is done through a protocol.
There are, however, some limits to what application programming interfaces can do. You can’t use Windows DLLs to make a Linux application, or the iOS SDK to build an Android app. At least not without a LOT of caffeine and experimentation, and even then there would be no guarantees the end product would work.
Ultimately, it all comes down to compatibility: a software development kit targets a specific platform or environment, whereas most (including REST) APIs have a lot more flexibility.
Hopefully you’re now armed with all the knowledge you need to figure out how to choose between an API vs. a software development kit for your next project!