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

Kin Lane, API Evangelis t, для которого SDK составляют важную часть Контрольного списка для разработчиков.

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

Адам Дувандер, чей индекс DX состоит из 13 отдельных критериев, каждый из которых имеет весовую степень по важности. Вверху списка находятся библиотеки, доступные на популярных языках.

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

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

Многие поставщики API после того, как согласились с необходимостью раздачи SDK, задумались над тем, на каких языках они должны их предлагать? Золотой ответ - как можно больше. Сегодня разработчики работают с множеством языков и платформ, разнообразие, когда дело доходит до внедрения новых технологий, неизмеримо велико. Согласно опросу Программируемый Интернет, программисты чаще всего используют следующие языки для использования API:

  1. PHP
  2. Python
  3. Рубин
  4. .NET / C #
  5. Джава
  6. Perl
  7. Холодный синтез
  8. Node.js
  9. ActionScript

Некоторые из этих языков могут терять популярность, и новые языки принимаются день ото дня, но факт остается фактом: API-интерфейсы используются на нескольких языках, и вам необходимо удовлетворить эту потребность.

Что снова рождает вопрос:

Как вы собираетесь создавать SDK на всех этих языках?

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

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

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

Можно с уверенностью предположить, что для написания одного SDK разработчику, достаточно опытному для написания идиоматического кода, требуется полный рабочий день. Если предположить, что разработчик потратит неделю на создание и тестирование этого SDK при ставке оплаты 46 долларов в час (bls.gov), то окажется, что стоимость SDK на одном языке составит 1852 доллара.

Стоимость поддержки SDK зависит от многих переменных, таких как частота смены API или размер библиотеки. Для простоты предположим, что разработчику требуется в среднем два дня в месяц для поддержки SDK. При тех же предположениях о расходах затраты на обслуживание одного SDK в течение года составят 8 885 долларов. Суммируя затраты на создание и обслуживание, мы получаем цифру в 11 000 долларов за API на SDK для каждого языка.

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

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

Мечта о SDK со всеми затратами и усилиями превращается в кошмар SDK. Многие даже ставят под сомнение их ценность и ценность.

«Необходимость - мать изобретений»

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

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

Что такое генераторы кода?

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

APIMatic CodeGen Engine принимает спецификацию API в любом формате (Swagger / OpenAPI, RAML, API Blueprint и т. Д.) И предлагает полнофункциональные SDK, в которые входят:

  • Клиентские библиотеки
  • Образцы динамического кода
  • Документация
  • Руководства по началу работы

И все это на разных языках программирования!

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

Вот что мы делаем для автоматического создания SDK для вас:

  1. Возьмите описание API в любом популярном формате
  2. Преобразуйте его в наш стандартный язык описания (SDL) или формат APIMatic.
  3. Проведите серию проверок
  4. Зациклить различные части описания API и сгенерировать представления кода
  5. Преобразуйте важные объекты из описания API в SDK.
  6. Создайте уровень абстракции HTTP, чтобы обернуть HTTP-клиента
  7. Создайте один или несколько файлов вспомогательных классов, чтобы абстрагироваться от большого количества общего кода из SDK.
  8. Предоставьте интерфейс клиентской библиотеки, чтобы обернуть SDK и упростить его использование.
  9. Создание файлов, зависящих от языка или платформы, таких как gemspec, Gemfile и Rakefile, которые создаются для пакетов SDK Ruby.
  10. Создание файлов Readme, руководств по началу работы, примеров кода и документации
  11. Упакуйте все в zip-файлы, готовые к развертыванию на GitHub или в определенных репозиториях.

Подробно узнайте, как мы обеспечиваем автоматическое создание SDK



Все это может показаться действительно сложным процессом, но мы считаем, что провайдерам API не следует об этом беспокоиться. APIMatic здесь, чтобы делать тяжелую работу, мы здесь, чтобы производить полностью работающие качественные SDK, а для достижения всего этого от регистрации до вашего первого поколения SDK потребуется меньше минуты. Используйте API CodeGen от APIMatic, чтобы встроить движок в конвейер CI / CD и никогда больше не беспокоиться об обновлении SDK!

Узнайте, как Pepipost использовал SDK, созданные APIMatic, для упрощения процесса интеграции.



АВТОГЕНЕРИРУЙТЕ СВОЙ ПЕРВЫЙ SDK СЕГОДНЯ. ПОПРОБУЙТЕ БЕСПЛАТНО!

Другой вопрос, который вызывает недоумение у многих провайдеров, заключается в том, что, если они хотят, чтобы их SDK следовали определенным соглашениям. К счастью, им не о чем беспокоиться, CodeGen Engine APIMatic не создает универсальных, подходящих для всех SDK. С помощью наших настроек CodeGen мы позволяем поставщикам выбирать, что работает или не работает для них, например

  • Автоматическое добавление заголовков JSON accept и content-type
  • Разрешение пропуска проверки SSL-сертификата
  • Установка тайм-аутов для вызовов конечной точки
  • Выполнить линтинг

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

Сервис CodeGen от APIMatic - это больше, чем просто генератор кода, это целая платформа. Где ты можешь

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

Не знаете, как встроить API Code Engine в свой конвейер? Свяжитесь с нами сегодня, чтобы заказать демоверсию!