How SDK and API operate

Definitions first.

An API (application programming interface) is a set of protocols and tools that ensure data exchange between different components of information systems.

Thanks to API, mobile apps can easily use Yandex.Maps or Google Calendar — both corporations provide third-party developers with ready-made tools to embed these modules into new products. This is exactly the interface for connecting to external infrastructure (in our example, to Yandex and Google services) which enables app tasks to be solved with a set of HTTP requests. 

An SDK (software development kit) solves a more significant problem: it doesn't just ensure data exchange between an app and third-party infrastructure, but implements a full-fledged process. It can incorporate working components to receive user data, process and store it securely, and change its states.

The SDK may include several APIs, chunks of supporting code, and extensive documentation. This is not just an interface to interact with the system, but a ready set of tools for implementing business logic. Companies create an SDK so that third-party developers don’t have to plunge into the code, but tackle their problems via abstraction — one block ensures performance of a personal profile, another enables a smartphone camera, etc to be opened. Data security and fault tolerance of individual services are actually implemented via an SDK.

Simply put, if an API is a meal's recipe, then an SDK is a recipe, sliced products, specific doses of spices and herbs, and all the pots and pans one will need to cook it.  

API and SDK in True Engineering products

Each of our products uses the client's APIs to obtain data from the client's infrastructure.

In the insurance apps, that's the way we connect to the backend to download certificate lists and submit data on insurance claims. In the sales accounting systems and cashier apps the APIs are responsible for storing air-ticket data in the backend and uploading information for reports.

These are "local" applied problems that don't involve complex business logic. Therefore, they are dealt with via an API.

An example of when an SDK became a must – a unified car incident formalization module development project for insurance companies. This complex scenario combines login via ESIA, incident booking using the European accident statement, and data exchange with ST-GLONASS AIS OSAGO, traffic police and other authorities.

Using the SDK, we can wrap all the complex logic into a ready-to-use tool set that can later be embedded into any app. Such a module contains an API to work with with ESIA and systems of the Russian Association of Motor Insurers, means of protection and data verification, and components for operating a camera.

As a result, all insurance companies that will use this SDK in their apps will have an incident formalization scenario in compliance with the same standards. And they don’t have to spend their own resources to develop this scenario.

So, how to choose between SDK and API

• If a company grants its partners access to a specific function, an API is sufficient. In our insurance app example, this is how we get user certificate lists.
• If a service owner grants their partners access to a whole functional unit, preparing an SDK would be the better solution.