In any niche world of business there are acronyms and buzzwords that make up the industry's jargon. Sometimes it’s hard to keep up with all these trendy words and if you’re just getting into the industry you may not know many of them, and that is normal.
In the world of facial recognition there are many of these terms (FAR, FRR, and EER anyone?), but two important acronyms you may hear often are API and SDK.
It is vital to know what these terms mean, how they are different, and how they can come together in a product. So to help explain them, we’ll use the analogy of baking a cake.
API = Application Programming Interface
If you are going to bake a cake you need a recipe, which gives you instructions and rule guides. An API is like a recipe as it is a set of programming instructions and standards to use when accessing an online tool or database.
Most basic cake recipes are available online for free. Software companies often provide their API for free in a trial, allowing coders to create a proof-of-concept for their idea.
Sometimes when you are baking a cake you want to incorporate other recipes’ ingredients to your cake to take it up a level, ie; chocolate cake to double fudge brownie and strawberry cream chocolate cake. When you are creating an application you can incorporate many different APIs into your product to enhance it and give it additional features.
SDK = Software Development Kit
When you don’t feel like making a cake from scratch you may buy a premade cake mix. A cake mix requires you to add one or two additional ingredients, bake, and serve. This is a SDK, a devkit, which contains all the tools you need to build a specific type of product like documentation, programming tools, and APIs.
A SDK may contain an API, or even sometimes many APIs. So an API is part of a SDK but a SDK is never part of an API. Got it?
An API is a set of operations that a developer can use to access the backend of a server, assuming that the service is on a remote server. You use the API by calling it from your device to the Cloud (a bunch of servers connected to the Internet) running the service. This is a Representational State Transfer (REST, which is another story) based API, although not all APIs are REST.
A SDK is a group of tools, including pieces of code, that gets embedded into a service. The SDK contains APIs and so, it calls on the API when necessary to execute tasks. The result is the developer calls the SDK locally and the SDK calls the API remotely.
So technically speaking, an API is used as a part of a build to ingest information while a SDK is a set of tools you used to build something new. Going a little deeper, an API has a set way to interact with a specific platform like OS X, Android, project software, etc; and a SDK will make a be a nice little package of things a developer needs to create a product, software, and/or application.
Back to the Cake...
Without an API or SDK you would have to code your project from scratch. So, that means if you were baking a cake you would not only need to get all the ingredients yourself but you would have to create the recipe out of thin air and then build your own cooking tools.
If you want to create a mobile banking application that uses facial recognition to verify and identify a customer before they deposit a check, you will need help with the facial recognition part. The technical pieces behind a functional facial recognition piece of code would be too complex and costly of a project to create from scratch when you just need it as a add-on feature within your application.
This is where you decide if you should use an API or a SDK. A facial recognition API would most likely be what you needed for your mobile banking app as you could easily create a proof-of-concept before integrating it into your current code base.
A SDK may offer too many additional features, and take additional time to set-up in your development environment. It would be a better option to build the framework of the whole application, if you had not done that already.
4 Common Objections to Using the Kairos API
The following statements are aggregated from hundreds of customer interviews we performed over the last 12 months:
- “I need it to process faces in real-time”
You don’t want to add latency with the ‘round-trip’ of sending a call into an API and waiting for the response.
- "I need it to work offline, with no connection”
You have scenarios where you can't connect to the ‘Cloud’, you require a sense of control security and you are looking to save money on bandwidth costs - perhaps you have a remote location, or device with no network capability.
- “It’s slow (and expensive) to process video over the cloud”
This is similar to #1 and #2, but you might not want to send loads of video over the internet.
- “I need to control my data and security”
You have doubts about how secure an API can be, and whether you can still manage your own data.
Whilst the statements above are perfectly reasonable, we wanted to share them here so anyone reading this wouldn’t feel alone in thinking them too. And it talks to why we wrote this article; we wanted to get to the root of what our customers are trying to achieve - their bigger goals and outcomes.
So, we always ask “Do you really need to do these things in order to get started?”. When we begun framing the conversation like this, we started to see (in most cases) these objections actually turn into opportunities. And that’s why we will always recommend to our customers they get started with our APIs - especially at the proof-of-concept stage.
And # 4 deserves special attention because we take security & privacy seriously. We have made it a point to keep customer information secure, safe, and anonymous. We are hosted at Amazon Web Services (AWS) and are a Standard Technology Partner of AWS. We offer 2048 bit SSL encryption, and tokenisation, for all data in transit and our backups. For more information on AWS, visit their compliance page. For our more sophisticated Enterprise customers we offer a version of our service that lives in their infrastructure further protecting the most sensitive of data.
Kairos' Face Recognition API and SDK
At Kairos we offer both a SDK and an API and our customer support can help you decide which product is best for your needs. However, we suggest starting with our API as it’s a quick solution that you can easily integrate into your product today. Even if you are interested in our SDK, and have a developer team to use it, we still encourage you to start using the API and then transitioning to the SDK later on. Again, the answer is that time is money and the API can be used right now while the SDK may take a bit longer to set up.
For both our API and SDK we created documentation which will help you understand what each service can do and how long it will take to integrate with. Depending on your API plan we also offer a range of different support options - from community based to hands on consultative services.
Also, before you go on the journey of researching different face recognition providers, and their features, just read our handy comparison of the best face recognition APIs. We spent many months compiling the data from hundreds of customer interviews and market analysis - we’re humbled by the positive feedback we’ve had so far.
Try the Kairos face verification demo
Developer? - click the little 'SHOW JSON' link to see some live code.
API or SDK, Confusion No More
So now that we’ve discussed the differences between APIs and SDKS, and how to use each one depending on your needs, you may be wondering how this was ever confusing to begin with!
We think the confusion comes from the integration of an API within a SDK and how they overlap one another but when you understand that they are two different entities it’s a little bit easier to understand.
And, when APIs and SDKs are easier to understand you can go ahead with your project, cuddle up to your computer, and enjoy a piece of cake. Now the only hard decision will be what flavor.