Что такое sdk в программировании

SDK тебе, SDK мне, SDK всем! Как делать SDK и зачем это нужно

Наша компания делает сервис для хранения и обработки данных с промышленных устройств (насосы, буры и прочая промышленная техника). Мы храним данные наших клиентов и предоставляем функционал для их анализа: построение отчетов, графиков и еще много чего.

И в ходе работы мы заметили, что интеграция каждого нового клиента сильно затягивается, а количество различных ошибок постоянно возрастает. Тогда стало понятно, что пора с этим разобраться. Как показал анализ ситуации, IT отдел каждого нашего клиента разрабатывал свое решение для локального сбора данных с устройств и отправки к нам в сервис. Все усложняет то, что с учетом специфики отрасли, не всегда есть доступ к интернету и необходимо хранить данные локально и отправлять при первой возможности. И таких нюансов достаточно большое количество, что и приводит к росту количества ошибок.

И тогда мы поняли, что лучшим решением в данной ситуации будет разработать SDK и предоставлять его клиенту. Сразу же начал искать лучшие практики и рассуждения на тему разработки SDK и сильно удивился — в рунете об этом практически ничего нет, а в басурманских интернетах очень мало информации и она разрознена. Ну что ж, задача понятна, обдумана и реализована.

Но именно отсутствие информации на данную тему породило желание рассказать сообществу о размышлениях, принятых решениях и выводах на тему разработки SDK. В статье рассматривается решение для .NET, но речь идет о концепции, так что будет интересно многим. Подробности под катом!

Пора определяться

Начнем с того, что определим, что такое SDK и зачем он может быть нужен.

SDK (от англ. software development kit) — комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ. SDK использует преимущества каждой платформы и сокращает время на интеграцию.
…
Инженер-программист обычно получает SDK от разработчика целевой системы.

Что ж, логично. Простыми словами, SDK — это пакет библиотек, для того, чтобы клиент мог легко и быстро начать работать с вашей системой (в данной статье речь пойдет про наш сервис, но всё изложенное в статье применимо и к другим видам SDK) или выполнять однотипные действия.

Но, как и у любого подхода, у «Пути SDK» есть как преимущества, так и недостатки.

Преимущества

Высокая скорость интеграции нового клиента — вашим клиентам нужно писать меньше кода.

Переиспользование кода — один и тот же код используется сразу в нескольких местах. Можно сказать, что это дублирование предыдущего пункта, но речь идет о том, что логика работы везде одинокава, из чего следует

Предсказуемость поведения — использование одних и тех же библиотек приводит поведение систем к определенному стандарту, что сильно облегчает поиск и устранение ошибок и уязвимостей.

Качество кода — много где любят экономить на тестировании (жалко бюджета, горят сроки и прочие причины). Понятно, что в реальном мире покрыть тестами все участки проекта это учень трудоемкая задача. Но качественно протестировать все модули SDK, а затем использовать их — это путь повышения процента покрытия тестами, что приведет вас к снижению количества ошибок.

Документация — тот же сценарий, что и с тестами. Покрыть документацией весь проект достаточно проблематично. Переиспользование модулей SDK повышает процент покрытия документацией, что снижает порог вхождения новых сотрудников в проект и вообще помогает по жизни.

Все преимущества, по сути, это следствия самого главного — мы очень качественно пишем код один раз, а затем его переиспользуем.

Недостатки

Высокие требования к качеству кода SDK — следствие главного преимущества. Ошибка в SDK породит ошибки во всех системах, его использующих.

Установка ограничений — SDK — это набор библиотек для реализации стандартных сценариев. Иногда разработчики SDK полагают, что кроме реализации одного из предусмотренных сценариев клиенту ничего не потребуется, что клиенту проще сделать все с нуля самостоятельно, чем строить пьедестал из костылей для SDK.

Dependency hell и обновления — при расширении функционала (например, кастомизации решения под конкретного клиента), вы выпустите новую версию библиотеки. Но существуют зависимости, различные наборы версий библиотек у разных клиентов, и нужно очень тщательно следить за обратной совместимостью или строгим версионированием.

Когда SDK действительно нужен

У вас есть несколько стандартных сценариев, которые реализуются заново из раза в раз — собственно, наш случай.

Внутренние разработки — в разных проектах вы используете системы логирования, конфигурирования систем, работу с HttpRequest, БД, файлами? Выработайте внутренний SDK — набор библиотек для внутреннего использования. Вы в любой момент можете расширить функционал SDK, но скорость разработки новых проектов, процент покрытия тестами и документацией вырастет, а порог вхождения новых разработчиков снизится.

Когда SDK скорее всего будет лишним

Сценарии использования не определены или постоянно меняются — оставьте реализацию кастомных решений клиентам и помогите им. Не надо городить вундервафлю, которая будет только мешать. Очень актуально для молодых компаний и стартапов.

Вы не умеете делать качественно — у меня для вас плохая новость: пора учиться. Но отдавать кривое решение клиенту это очень, очень неправильно. Клиентов надо уважать, в конце концов.

Итак, мы определились, что такое SDK, с его преимуществами и недостатками и когда он нам нужен. Если после этого вы поняли, что SDK действительно нужен — приглашаю вас встать на «путь SDK» и разобраться, а каким он должен быть и как его, черт подери, делать?

«А вы любите Lego?» — Модульность

Представим все возможные сценарии использования SDK (вы же уже определились, зачем он вам нужен, правда?) и сделаем по библиотеке на сценарий. Чем не выход? Но это плохой подход, и так мы делать не будем. А будем так:

разобьем все сценарии на шаги
выявим общие шаги
построим список модулей, реализующих все возможные шаги (один модуль отвечает за реализацию чего-то конкретного, например, работы с конфигурациями)

Например, с учетом специфики задачи, нам необходимо, чтобы вся логика задавалась из конфигов. Реализуем модуль работы с конфигами (чтения, записи, обновления, валидации и обработки конфигураций) и будем использовать его во всех остальных модулях.

А для реализации стандартных сценариев мы действительно сделаем модули — этакие «управляющие» модули, каждый из которых реализуют один конкретный сценарий, используя другие модули того же SDK. Таким образом для реализации стандартных сценариев клиент должен лишь подключить управляющий модуль сценария (а он сам подтянет все зависимости), а для реализации нестандартных — используем базовые модули, так же переиспользуя код.

Именно этим обусловлено то, что SDK не должен быть одной библиотекой (хотя очень хочется, понимаю. Ведь когда весь SDK в одной библиотеке, можно забыть о зависимостях и всем, что с ними связано), а быть комплектом библиотек. Дополнительным плюсом данного подхода будет уменьшение «веса» программы клиента — он будет тянуть тяжеловесный SDK, а подтянет только необходимые модули.

Но не стоить плодить модули как попало, ведь чем больше модулей, тем больше головной боли от их зависимостей! Т.е. важно правильно разбить логику на модули, соблюдая баланс между решением «все в одном» и «на каждую функцию свой модуль».

«А что, так можно было?!» — Универсальность

Предоставьте клиенту различные интерфейсы для работы с вашей библиотекой. Приведу пример:

public void LoadConfiguration(string filename); public async Task LoadConfigurationAsync(string filename);

Если предоставить только синхронную версию, то при реализации асинхронного приложения клиент вынужден будет делать асинхронные обертки вашего синхронного метода. Если предоставить только асинхронную версию — ситуация похожа. Дайте клиенту и то и другое и он скажет вам спасибо.

Приятным плюсом будут дженерики. Например, у нас есть класс для работы с конфигурациями, реализующий методы упаковки конфига в строку, загрузки конфига из файла и т.д. Конфигурация конкретного модуля будет наследоваться от нашего базового класса, но для работы с новым классом нам необходимо также предоставить методы распаковки.

class BaseConfiguration < public BaseConfiguration FromString(string source)public BaseConfiguration FromString(string source,Type configurationType) public T FromString(string source) where T:BaseConfiguration > class CustomConfiguration : BaseConfiguration<>

Таким образом мы предоставили клиенту аж три реализации, которые он может использовать. Дженерики очень удобны, но при работе с динамическими типами их можно вызывать только через рефлексию, что накладно. Общий принцип универсальности, надеюсь, понятен.

«Родитель 1, Родитель 2, Дети[ ]» — Именование

Что самое трудное в работе программиста? Выдумывать имена для переменных.

И тем не менее… Правильное именование модулей, классов, свойств и методов сильно помогут тем, кто будут с вашим SDK работать. Пример, не требующих комментариев:

Kinect 2.0 SDK example

var skeletons = new Skeleton[0]; using (var skeletonFrame = e.OpenSkeletonFrame()) < if (skeletonFrame != null) < skeletons = new Skeleton[skeletonFrame.SkeletonArrayLength]; skeletonFrame.CopySkeletonDataTo(skeletons); >> if (skeletons.Length == 0) < return; >var skel = skeletons.FirstOrDefault(x => x.TrackingState == SkeletonTrackingState.Tracked); if (skel == null) < return; >var rightHand = skel.Joints[JointType.WristRight]; XValueRight.Text = rightHand.Position.X.ToString(CultureInfo.InvariantCulture); YValueRight.Text = rightHand.Position.Y.ToString(CultureInfo.InvariantCulture); ZValueRight.Text = rightHand.Position.Z.ToString(CultureInfo.InvariantCulture);

Всё ясно из названий классов и методов. А если есть автодополнение кода в вашей IDE, то зачастую можно и в документацию не заглядывать, если и так все понятно.

«Уверен, если бы Смерть знала, что такое бюрократия, люди бы никогда не умирали, вечно стоя в очереди. » — Документация

Но даже если у вас очень красиво и актуально названы все модули, классы, методы и свойства, документацию все равно необходимо написать. Во-первых, это очень сильно сбережет вам нервы (количество вопросов клиентов уменьшается на порядок. Все есть в документации), а во-вторых, всегда понятно, почему вы сделали так, а не иначе.

Документация, в SDK, как правило, проста и лаконична. Она обычно делится на две части: Tutorial — пошаговый курс в стиле “Построим город за 10 минут” и раздел Reference — справочник по всему, что можно сделать с помощью данного SDK.

Мы выбрали самый простой путь — summary + articles. Мы добавляем Xml атрибуты для методов и классов, которые светятся в intellisense как подсказки. Используя Docfx мы строим документацию по этим атрибутам и получаем подробную и удобную документацию, которую дополняет статьями, описывающими сценарии использования и примеры.

«— Чтобы чисто было! — Как я буду вилкой-то чистить?» — Тестирование

Что можно сказать про тестирование в рамках обсуждения SDK… Must have! Лучшим решением будет TDD (несмотря на то, что я негативно отношусь к данному подходу, в данном случае я решил использовать именно его). Да, долго. Да, нудно. Но зато в будущем вы не повеситесь от постоянных падений SDK на стороне и следствий этого падения.

Основной сок ситуации заключается в том, что отдавая SDK клиенту вы теряете контроль: вы не можете быстро пофиксить ошибку, сложно эту самую ошибку найти, да и выглядеть в такой ситуации вы будете достаточно глупо. Поэтому — тестируйте. Тестируйте лучше. И еще раз. И, на всякий случай, протестируйте ваши тесты. И тесты тестов. Так, что-то я увлекся, но важность тестирования SDK, надеюсь, понятна.

«Жертва, которая не могла противостоять своему прошлому, была поглощена им» — Логи

Поскольку вы отдаете SDK сторонней компании, в следствие чего теряете контроль над ситуацией, в случае ошибки (на этапе тестирования вы все-так решили «и так сойдёт», да?) вас ждет достаточно долгий и болезненный процесс поиск этой самой ошибки. Именно тут вам на помощь придут логи.

Логируйте все, абсолютно все, а в случае возникновения ошибки запросите у вашего клиента логи. Таким образом вы сэкономите много времени и сможете не потярять лицо перед клиентом.

«Alarm! Achtung! Attention!» — Ошибки

Долго размышляя на тему ошибок я пришел к интересному выводу — ни один метод в вашем SDK не должен отдавать ошибку, не описанную в документации. Согласитесь, очень неприятно, когда вы подключаете стороннюю библиотеку для работы с HttpRequest, а она вываливает на вас какой-нибудь NullPointerException и StackTrace, который уводит в недра библиотеки. И вам приходиться погружаться в эти самые «недра», пытаясь понять, насколько глубока кроличья нора, и в чем, собственно, проблема.

Поэтому я предлагаю следующее решение — декларируйте закрытый список возможных исключений и документируйте их. Но, т.к. нельзя быть увереннным, что вы предусмотрели все, оберните метод в try-catch, а пойманную ошибку — в задекларируему. Например, ConfigurationException, который будет содержать InnerException — пойманную ошибку. Это позволит стороннему разработчику поймать все возможные ошибки, но в случае чего быстро разобраться в чем дело.

Версии или «как не укусить себя за хвост»

Во избежание проблем в будущем крайне рекомендую использовать строгое версионирование. Выберете подходящую вам систему построения версий и используйте ее. Но если новая версия библиотеки не имеет обратной совместимости — это необходимо указать. Как это разруливать — думать вам. Но подумать об этом точно стоит.

«Паровозик, который смог» — Deploy

Необходимость актуальности документации и версий порождают требование к корректности деплоя. В своем решении мы используем следующее решение (костыли, но работают).
Когда надо выпустить нвый релиз, разработчик дергает bat’ник с указанием номера релиза, а затем батник:

билдит релиз
кладет все библиотеки в архив
билдит свежую версию документации (docfx)
указывает версию релиза в документации и в названии архива
кладет всё самое свеженькое в гит-репозиторий
WebApp на MS Azure подтягивает свежий коммит по гит хуку и публикует изменения

На выходе получаем обновленную версию сайта с документацией, откуда можно скачать архив с последней версией SDK.
В планах на будущее — упаковка всего в Nuget пакеты и публикация в локальный Nuget репозиторий.

Рекоммендую обратить внимание на этот пункт, ведь вы можете существенно снизить количество головной боли, вызванной отсутствием актуальной информации о новой версии библиотеки.

«-А так можешь? — Фигня. Смотри как надо!» — Примеры & toolkit

Важным пунктом документации являются примеры использования. Но помимо этого, зачастую требуется предоставить не библиотеку, а приложение, которое реализует самые стандартные сценарии. Рекомендую делать эти приложения с открытым и хорошо прокомментированным исходным кодом, что позволит убить двух зайцев разом — предоставить работающее приложение и предоставить пример использования SDK.

Заключение

Разработка SDK стало для меня интересной новой задачей, поднявшей много важных архитектурных вопросов. Многое описанное в статье является очевидными вещами (для меня), но считаю важным огласить даже очевидные вещи, чтобы получить четкую общую картину.

P.S.

Спасибо за прочтение, буду рад вашим комментариям. Надеюсь, эта статья будет для вас полезной.

Что такое пакет SDK?

Пакет средств разработки ПО (SDK) – это набор инструментов для разработчиков, ориентированных на платформу. Для создания кода, работающего на определенной платформе, операционной системе или языке программирования, требуются такие компоненты, как отладчики, компиляторы и библиотеки. Пакеты SDK содержат все необходимое для разработки и запуска программного обеспечения в одном месте. Кроме того, они содержат такие ресурсы, как документация, учебные пособия и руководства, а также API и платформы для ускорения разработки приложений.

Какие преимущества использования пакета SDK?

Пакеты SDK обеспечивают ряд преимуществ в процессе разработки, которые помогают разработчикам создавать приложения. Эти следующие принципы:

Эффективная разработка

Пакеты SDK повышают эффективность разработки, предоставляя готовые компоненты и библиотеки, которые можно встраивать в приложения. Эти компоненты значительно экономят разработчикам время, которое ранее тратилось на программирование и отладку с нуля.

Ускоренное развертывание

Пакеты SDK ускоряют развертывание, предоставляя инструменты, позволяющие разработчикам быстро создавать и интегрировать приложения. Они часто поддерживают несколько платформ, что позволяет разработчикам быстро развертывать их на нескольких устройствах или операционных системах.

Интеграция

Пакеты SDK предоставляют разработчикам встроенные модули, компоненты, пакеты и инструменты для создания, тестирования и развертывания программных приложений. Они упрощают разработку, тестирование и интеграцию с другими системами и сервисами, образцами кода и учебными пособиями, инструментами отладки и библиотеками кода.

Сокращение затрат

Пакеты SDK сокращают время и ресурсы, необходимые для разработки приложений. Благодаря библиотеке встроенных компонентов и инструментов SDK позволяют разработчикам быстро создавать функции и функционал. С пакетами SDK можно быстрее создавать новые приложения с меньшими затратами. Они также снижают издержки, связанные с развертыванием и обслуживанием приложений, что упрощает процессы установки и обновления.

Как можно использовать пакеты SDK?

Существует несколько вариантов использования SDK, в том числе следующие:

Разработка мобильных приложений

Пакеты SDK предоставляют разработчикам инструменты, библиотеки и другие ресурсы для разработки мобильных приложений. Они включают компоненты для отладки, мониторинга и оптимизации производительности мобильных приложений. Разработчики могут создавать элементы пользовательского интерфейса, получать доступ к данным и интегрировать приложение со сторонними сервисами. Кроме того, пакеты SDK упрощают развертывание приложений на разных платформах, таких как iOS или Android.

Веб-разработка

Пакеты SDK предоставляют разработчикам инструменты, необходимые для создания интерфейсов веб-приложений, таких как HTML, CSS и JavaScript, а также серверные ресурсы, например базы данных, серверные языки программирования, платформы и API. Кроме того, они предоставляют инструменты развертывания для хостинга и масштабирования.

Облачные вычисления

Пакеты SDK предоставляют API и библиотеки для подключения к облачным сервисам хранения или для доступа к облачным вычислительным сервисам, таким как базы данных, аналитика или машинное обучение. Разработчики используют их для интеграции с облачной средой на предпочитаемом языке.

Интернет вещей (IoT)

Разработчики используют SDK для создания приложений Интернета вещей, взаимодействующих с датчиками. Это позволяет им разрабатывать приложения для мониторинга, сбора и анализа данных из окружающей среды. Кроме того, вы можете более эффективно управлять обновлениями прошивки и ПО устройства, поскольку пакеты SDK часто содержат обновления и исправления безопасности.

Разработка игр

Игровые пакеты SDK часто поставляются с образцами кода, руководствами и другими ресурсами, помогающими разработчикам создавать игры. Библиотеки 3D-графики, аудиотеки, физические движки, библиотеки искусственного интеллекта, сетевые библиотеки и инструменты разработки – все это стандартные игровые компоненты.

Какие инструменты обычно используются в SDK?

В наборах для разработки программного обеспечения обычно есть разные инструменты и строительные блоки для создания программного обеспечения, Примеры перечислены ниже.

Библиотеки API

Библиотеки интерфейса прикладного программирования (API) – это коллекции кода, написанного на определенном языке программирования, таком как Java, C# или Python. Вы используете API для доступа к определенным функциям, программным приложениям или операционным системам, таким как iOS или Android.

Отладчики

Отладчики обнаруживают и исправляют ошибки в программном коде, обеспечивая доступ ко внутренним компонентам программ в режиме реального времени. Стандартные функции отладки включают установку контрольных точек для приостановки программы, проверку значений переменных и построчную проверку кода.

Компиляторы и интерпретаторы

Компиляторы и интерпретаторы преобразуют код, написанный на языке программирования, в машиночитаемый код. Компиляторы генерируют исполняемые программы, а интерпретаторы напрямую запускают программы.

Профайлеры

Профайлеры анализируют производительность приложений, включая использование памяти, время выполнения и пути выполнения кода. Собирая и анализируя данные, профайлеры помогают определить области программы, в которых можно что-то оптимизировать или где могут возникнуть проблемы.

Образцы кода

Образцы кода – это фрагменты кода, которые разработчики используют для понимания и реализации конкретных концепций или функций. Образцы кода показывают, как использовать компоненты SDK, такие как библиотеки и API, для создания приложений.

Инструменты развертывания

Инструменты развертывания позволяют командам разработчиков развертывать свои приложения на целевой платформе, что может включать настройку приложений для соответствующей платформы и упаковочных приложений. Примеры инструментов развертывания включают установщики, средства автоматизации и мастера развертывания.

Интегрированная среда разработки (IDE)

IDE объединяет основные инструменты, используемые разработчиками для написания и тестирования программного обеспечения и отладки кода. IDE обычно включает редактор кода, компилятор, отладчик, менеджер проектов и систему управления версиями.

Как работает SDK?

Использование SDK обычно состоит из трех шагов:

Покупка или загрузка SDK, а затем установка пакета для конкретной платформы.
Использование SDK для разработки приложения в интегрированной среде разработки.
Использование инструкций, документации, образцов кода и инструментов тестирования, включенных в SDK, для эффективной разработки.

Разница между SDK и API

API – это набор инструкций по программированию, при помощи которых приложения могут взаимодействовать друг с другом. API-интерфейсы предоставляют приложениям возможность доступа к данным и обмена ими, как правило, с помощью серии запросов и ответов. Например, веб-API может дать возможность пользователю искать продукт на веб-сайте, а API предоставит соответствующую информацию в ответ. Разработчики используют API для интеграции своих приложений со сторонними сервисами, такими как социальные сети или платежные процессоры. API – это коммуникационный мост между двумя приложениями. С другой стороны, SDK привносят сторонние инструменты в среду разработчика.

Что следует учитывать при выборе SDK?

Выбранный вами SDK должен быть оптимизирован для вашего конкретного варианта использования, не замедлять работу приложения и обеспечивать необходимые меры безопасности для защиты данных пользователей. Некоторые соображения включают в себя следующее:

Лицензионное соглашение

Важно проверить лицензионное соглашение SDK, чтобы убедиться, что оно охватывает все необходимые варианты использования. Оно должно соответствовать требованиям законодательства и не содержать ограничений на использование или распространение разрабатываемых вами приложений. Важно понимать наличие ограничений в любых лицензиях с открытым исходным кодом, которые могут быть связаны с SDK.

Безопасность

Вы должны убедиться, что ваш SDK получен из авторизованных источников и не содержит вредоносного кода. Используемый вами SDK должен надлежащим образом документироваться, поддерживаться и регулярно обновляться для обеспечения безопасности.

Совместимость

При принятии решения о том, какой SDK использовать, важно обеспечить совместимость с инфраструктурой развертывания вашего приложения. Например, пакет SDK должен быть совместим с операционными системами всех устройств, которые вы планируете поддерживать. Кроме того, он также должен поддерживать язык, на котором написано ваше приложение, и обеспечивать возможность интеграции с другими языками.

Какие пакеты SDK предоставляет AWS?

AWS предоставляет пакеты SDK для многих популярных технологий и языков программирования. Они упрощают вызов сервисов AWS из приложений на соответствующем языке или технологии. Кроме того, AWS также предлагает пакеты SDK для предложений AWS SaaS, чтобы вы могли более эффективно использовать их в своем коде. Примеры перечислены ниже.

AWS SDK для .NET предоставляет упрощенные сервисы AWS с помощью упорядоченного набора библиотек, знакомых разработчикам .NET.
AWS SDK для Python объединяет приложения, библиотеки или скрипты Python с сервисами AWS.
AWS SDK для Ruby устраняет сложности программирования, предоставляя классы Ruby для многих сервисов AWS.
AWS SDK для Rust упрощает использование сервисов AWS, предоставляя разработчикам Rust упорядоченный набор библиотек.
AWS WorkDocs SDK предоставляет полный доступ к ресурсам сайта Amazon WorkDocs на уровне администратора или пользователя и, таким образом, устраняет сложности создания возможностей совместной работы и управления файлами в разрабатываемых решениях и приложениях.
SDK для Amazon Chime позволяет разработчикам приложений добавлять в них возможности голосового общения, видеосвязи и обмена сообщениями, в которых применяется машинное обучение.

Оформите бесплатную пробную версию AWS, чтобы начать использовать пакет AWS SDK, подходящий для своего бизнеса.

SDK и API: в чем разница?

Разработчики программного обеспечения пользуются основными инструментами: SDK и API. По сути, как SDK, так и API позволяют улучшить функционал приложений, не прибегая к большим усилиям.

Что такое SDK?

Аббревиатура SDK расшифровывается как software development kit. SDK, или devkit, — это набор средств для разработки ПО под определенную платформу. Он содержит компоновочные блоки, средства отладки, а зачастую фреймворк или группу библиотек кода, например набор подпрограмм для определенной операционной системы.

В стандартном SDK могут присутствовать как некоторые, так и все компоненты из списка ниже:

Компилятор: переводит с одного языка программирования на используемый вами.
Примеры кода: демонстрируют примеры приложений или веб-страниц.
Библиотеки кода (фреймворк): предоставляют фрагменты кода, часто используемые программистами.
Инструменты для тестирования и аналитики: предоставляют аналитические данные о работе продукта в тестовой и эксплуатационной средах.
Документация: содержит инструкции для разработчиков.
Средства отладки: помогают разработчикам обнаруживать ошибки в коде, чтобы публикуемый код работал как задумано.

Как работает SDK

SDK предоставляет инструменты, которые способствуют ускорению и стандартизации разработки приложений.

Приобретите, загрузите и установите набор SDK для своей платформы (например, предварительно подготовленные фрагменты сборки, примеры и инструкции).
Откройте и используйте любые API исредства разработки, необходимые для создания нового приложения, начиная с интегрированной среды разработки (IDE). Это пространство, в котором работает программист и установлено средство отладки.
При разработке используйте инструкции, документацию, примеры кода и инструменты тестирования, которые обеспечат вам и вашей команде хороший старт.

Примеры использования SDK

SDK — неотъемлемая часть разработки мобильных приложений. SDK имеют множество областей применения:

SDK для определенных языков программирования, например JSON и Java Developer Kit (JDK) для JavaScript и Java соответственно, используются для разработки программ на этих языках оптимальным и стандартизированным путем.
SDK для аналитики от Google и других компаний предоставляют данные о пользовательских действиях, поведении и путях их перемещения по сайту или приложению.
SDK для монетизации от Google, Facebook и других компаний упрощают интеграцию рекламы с существующими приложениями с целью получения дохода.

Преимущества SDK

Доступ к компонентам и инструкциям для разработки ПО: например, SDK для ритейла содержит все элементы, необходимые для приложений в этой отрасли (например, «Избранное», «Корзина», «Сохранить заказ», «Оформить заказ» и т. д.).
Ускоренная и слаженная интеграция: SDK упрощают стандартные процессы и предоставляют доступ к необходимой информации.
Сокращение цикла разработки, повышение эффективности развертывания и вывода продуктов на рынок: поскольку SDK созданы для информирования, предоставления необходимых инструментов и шаблонов, разработчики могут сфокусироваться на разработке своего продукта.
Встроенная поддержка и экспертные знания: нет необходимости искать ответы или нанимать дополнительных экспертов в свою команду; SDK уже содержат код, написанный экспертами, и всю необходимую сопроводительную документацию.
Контроль расходов: все перечисленное выше позволяет оставаться в рамках бюджета во время разработки и после развертывания.

Что такое API?

Аббревиатура API расшифровывается как application programming interface (интерфейс программирования приложений). API — и как отдельное решение, и в составе SDK — облегчает обмен данными между двумя платформами и позволяет сторонним разработчикам использовать функционал проприетарного ПО.

API можно рассматривать как соглашение между двумя сторонами. API не только обеспечивает возможность обмена данными, но и устанавливает его правила.

Поскольку некоторые API предоставляют интерфейс напрямую, термины API и «интерфейс» иногда взаимозаменяемы.

Чтобы внести ясность, стоит отметить, что API может состоять из двух компонентов:

Технические спецификации и документация: информация об интеграции и эффективном использовании API.
Интерфейс: доступ к нему осуществляется как напрямую, через ключевое слово (в случае веб-API), или косвенно, через отдельный интерфейс (в случае REST API).

Что представляет вызов API с технической точки зрения:

Как пользователь приложения, которому необходимо выполнить задачу, вы инициируете задачу из своего приложения, создавая запрос.
API совершает вызов к веб-серверу, передавая запрос. API знает, куда отправлять запрос, поскольку он передается в конечную точку API, обычно — URL сервера.
Запрос выполняет стороннее приложение или база данных, предоставляющие такой сервис.

API в картографии обычно используются для интеграции карты на веб-странице или в мобильном приложении.
API платежных сервисов обычно используются компаниями, занимающимися e-commerce, для повышения гибкости процесса покупки, что приводит к расширению базы потенциальных клиентов.
API метеорологических служб могут улучшить опыт пользователей спортивных приложений, поисковых систем и т. д.

Объединение разнородных программных приложений для создания более сильного продукта
Сокращение цикла разработки за счет автоматизации
Снижение нагрузки на штатные ресурсы
Повышение узнаваемости бренда и доверия к нему
Максимально эффективное предоставление новых сервисов конечным пользователям

Нужно ли выбирать между SDK и API?

Нет, ведь как сказано выше, SDK зачастую имеет по меньшей мере один API. Они выполняют разные функции, но могут работать и помогать вместе.

Следует иметь в виду, что с использованием API и SDK связаны некоторые сложности. Одна из них заключается в потенциальных уязвимостях. Другая сложность, относящаяся к SDK, — частота обновлений. Поэтому важно, чтобы команды DevOps держали вопрос информационной безопасности в поле зрения, а также следили за своевременным обновлением компонентов.

Оригинальный материал на английском языке доступен по ссылке.

Как работают SDK и API

SDK и API – это инструменты, которые позволяют интегрировать ИТ-продукты с внешними системами. В этой статье мы расскажем, чем отличаются эти два понятия и как разработчики применяют их для своих задач.

Начнём с определений.

API (application programming interface, программный интерфейс приложения) – это набор протоколов и инструментов, которые обеспечивают обмен данными между разными компонентами информационных систем.

Благодаря API мобильные приложения могут легко использовать «Яндекс.Карты» или «Календарь» от Google – обе корпорации предоставляют сторонним разработчикам готовые инструменты, чтобы встраивать эти модули в новые продукты. Это именно интерфейс для подключения к внешней инфраструктуре (в нашем примере – к сервисам Яндекса и Google), который позволяет решать прикладные задачи набором HTTP-запросов.

SDK (software development kit, средства для разработки ПО) решает более масштабную задачу: не просто обеспечить обмен данными между приложением и сторонней инфраструктурой, а реализовать полноценный процесс. Он может включать в себя рабочие компоненты для получения пользовательских данных, их безопасной обработки и хранения, изменения состояний.

В SDK могут входить несколько API, куски вспомогательного кода, обширная документация. Это не просто интерфейс для работы с системой, а готовый набор инструментов для реализации некой бизнес-логики.

Компании создают SDK, чтобы сторонние разработчики могли не погружаться в код, а решать свои задачи через абстракцию – вот этот блок обеспечивает работу личного кабинета, этот позволяет открыть камеру смартфона, и т.д. Безопасность данных, отказоустойчивость вызовов отдельных сервисов реализуются именно через SDK.

Попросту говоря, если API – это рецепт блюда, то SDK – это рецепт, нарезанные продукты, чётко отмеренные специи и набор всех кастрюль-сковородок, которые вам понадобятся в готовке.

API и SDK в продуктах True Engineering

В любом нашем продукте используются API заказчиков, чтобы получать данные из клиентской инфраструктуры.

В страховых приложениях мы таким образом подключаемся к бэкенду, чтобы загружать списки полисов, отправлять данные о страховых случаях. В системах учёта продаж и приложениях для кассиров API отвечают за сохранение в бэкенде данных по авиабилетам и выгрузку информации для отчётов.

Это прикладные задачи «местного значения», которые не включают в себя сложную бизнес-логику. Поэтому они решаются посредством API.

Пример, когда возникла необходимость в SDK – это проект по созданию единого модуля для оформления ДТП для страховых приложений. Этот сложный сценарий объединяет авторизацию через ЕСИА, регистрацию происшествия с оформлением европротокола, обмен данными с СТ-ГЛОНАСС АИС ОСАГО, ГИБДД и другими компетентными органами.

Используя SDK, мы можем заключить всю сложную логику в готовый к использованию набор, который затем можно встраивать в любые приложения. Такой модуль включает в себя API для работы с ЕСИА и системами Российского союза автостраховщиков, средства защиты и проверки данных, компоненты для работы с камерой.

В результате у всех страховых компаний, которые будут использовать этот SDK, сценарий оформления происшествий в приложениях будет отвечать единым стандартам. При этом тратить собственные ресурсы на разработку такого сценария им не придётся.

Итак, как выбрать между SDK и API

Если компания открывает партнёрам доступ к некой отдельной функции, достаточно API. В нашем примере про страховые приложения так мы получаем списки полисов у пользователей.
Если же владелец сервиса предоставляет партнерам доступ к целому функциональному блоку, более правильным решением будет подготовить SDK.