Привет, Хабр! Меня зовут Анастасия Иванова, я технический писатель МТС Exolve. В этой статье я расскажу о том, что отпугивает начинающих и опытных разработчиков от работы с API, где чаще возникают проблемы и как можно изменить ситуацию.
Программный интерфейс упрощает внедрение коммуникационных сервисов в корпоративное ПО. Но разработчики неохотно используют API для внедрения. И дело не в их нежелании разбираться в технической документации, а в объективных причинах, которые могут повлиять на надёжность приложения, сохранность корпоративных данных, простоту сопровождения кода.
Но, согласно исследованию Synergy Research Group, рост в сегменте PaaS составляет более 29%, или 195$ млрд в денежном выражении. То есть всё больше бизнесов используют облачные решения.
Разберёмся, чего именно опасаются разработчики.
Некачественная разработка API
Удобство использования программного интерфейса для интеграции коммуникационных сервисов в бизнес-процессы компании зависит от качества его разработки. По мнению Дэвида Макинтайра, главного архитектора программного обеспечения в компании Akamai Technologies, многие API страдают от низкого уровня продуктов. Об этом говорит и исследование An Empirical Study of API Evolution and Stabilization. Поэтому программисты не могут полноценно использовать программный интерфейс для реализации своих инструментов.
На рынке ПО есть средства для разработки программных интерфейсов и управления ими. Но конечное качество всё равно зависит от команды, которая занимается поддержкой API.
При выборе инструмента для создания коммуникационных решений предпочтение следует отдавать онлайн-платформам от крупных компаний. Конечные разработчики в этом случае получают гарантии того, что API продолжит развиваться и уже используемые программы сохранят свою функциональность.
Нет стандартизации
Каким бы странным ни было это утверждение, одной из проблем API было и остаётся отсутствие общепринятых стандартов. Именно стандартизация занимает верхнюю позицию в списке опасений, уступая даже безопасности, которая находится на третьем месте. В результате перед использованием программного интерфейса специалистам приходится изучать документацию, а также знакомиться с общими принципами, которые используют в конкретном решении.
Согласно исследованию Postman, отсутствие документации для использования API — препятствие для 55% опрошенных респондентов. Стандартизация приводит к путанице при составлении документации. Отсюда вытекают проблемы с изучением программных интерфейсов.
Для бизнеса есть негативные последствия:
увеличиваются затраты ресурсов, необходимые для решения поставленной бизнесом задачи;
замедляется выпуск конечных продуктов, использующих интерфейс;
сокращаются возможности для обработки данных в режиме реального времени.
Сложность поддержки кода
Проблема при внедрении коммуникационных API — достаточно сложный процесс внесения изменений в существующий код. Модификация программного интерфейса проводится с учётом общих политик управления информационными процессами.
Эта процедура требует много времени и ресурсов. 62% опрошенных разработчиков считают, что сложный код поддерживать в 2 раза тяжелее, чем простой.
При изменении API может нарушиться работоспособность программ. Это приведёт к временному сбою используемых инструментов, а значит, к прямым и косвенным убыткам.
При выборе онлайн-сервиса для запуска собственных коммуникационных решений с использованием предоставленного API обращайте внимание на качество работы службы поддержки. Скорость реагирования и эффективная помощь позволят избежать остановки работы прикладных решений.
Нет готовых решений
API в чистом виде — это просто набор методов программирования в виде простых функций. С его помощью напрямую нельзя решить конкретную бизнес-проблему заказчика. Следовательно, чтобы получить нужный пользователю результат, необходимо самостоятельно разработать код. При использовании готового инструмента останется только внедрить его в существующие бизнес-процессы.
Но отсутствие готового решения — одновременно и сильная сторона API. Бизнесу не нужно адаптироваться под конкретный программный продукт. Наоборот, разработчики делают те инструменты и утилиты, которые нужны для решения конкретной задачи. В результате достигается 100% эффективность использования IT-инфраструктуры.
Трудности с повторным использованием микросервисов
Упомянутые ранее исследования Smartbear и Postman говорят о том, что микросервисы, безусловно, стали ведущей и быстрорастущей технологической прослойкой в нише API. Они завоевали сердца разработчиков модульностью, гибкостью и скоростью.
Но у разработчиков есть повод избегать API и по этой причине. Есть проблема: в последние годы всё больше мнений о том, что с повторным использованием API или микросервисов есть трудности. Около 26% руководителей API-first упомянули об этом.
Всё дело в том, что расширение API — актуальная проблема для крупных организаций. Нередко в одной компании есть сотни API, многие из которых неизвестны командам. Это приводит к тому, что специалисты создают ещё больше избыточных API, и это усугубляет существующую проблему. В The Cloud Blog хорошо расписали трудности и решения.
Пустая трата времени и ресурсов
Главный риск некачественных API, которых избегают команды — это зря потраченное время и ресурсы.
Оказывается, горящие сроки и ограничения самих API — половина беды. Зачастую после разработки могут возникнуть неполадки в системах, и некоторым компаниям попросту приходится оказываться вообще от внедрения API.
Одна из причин этому: большинство компаний придерживается формального процесса тестирования API. То есть, если разработчики заранее знают, что интеграция API вызовет море багов, а тестирование не поможет, то, конечно, они стараются обойти любые API стороной.
Почему стоит использовать API
При всех перечисленных сложностях программный интерфейс всё же больше других инструментов подходит для организации коммуникационных процессов.
Причин использовать API масса, самая важная — скорость внедрения нужных вам функций в свои продукты. Более того, для доступа к API часто можно использовать практически любой язык программирования: Python, R, Java, JavaScript, Ruby и другие.
Повторное применение
Интеграция с каналами коммуникации — это всего лишь набор методов, которые выполняют конкретное действие. Их можно использовать для сборки небольшого приложения или полноценного программного решения любой сложности. Причём, если узконаправленные утилиты выполняют одну задачу, то собственный продукт на основе API можно использовать для разных целей. Это важно для обеспечения переносимости и масштабируемости решений.
Быстрота работы
Благодаря API инструменты нативно интегрируются в бизнес-среду компании. Используемые бизнесом CRM, CMS, программы для учёта продаж могут подключаться к сервису в онлайн-режиме и обмениваться данными.
Разработчик с учётом ТЗ заказчика может куда быстрее выбрать тип взаимодействия, порядок отправки и получения информации.
Универсальность
Программные интерфейсы широко используются в бизнес-сфере. Поэтому можно реализовать множество интеграций и построить целостную систему, которая эффективно решает бизнес-задачи и управляет внутренними процессами.
Максимальная гибкость
Если использовать эту технологию, можно решить большую часть корпоративных задач. Независимо от сложности сценариев и автоматизаций. Даже с учётом того, что IT-ландшафт современной компании представляет собой набор из связанных (или несвязанных) облачных приложений и традиционных решений.
API позволяют управлять данными и целыми частями инфраструктуры и легко встраивать их в существующие инструменты без их замены или серьёзной модификации.
Что выбрать
API — не единственно верный выбор для внедрения коммуникационных сервисов в работу компании. Удобнее для бизнеса использовать CPaaS-платформу, которую спроектировали и разработали в рамках единой концепции. В этом случае изучение документации к API займёт меньше времени, а программирование и поддержка приложений упростится даже при передаче от одной команды к другой.
Конечно, важно, чтобы у выбранных API вы сразу заметили актуальную документацию, образцы кода и примеры использования. Часто именно эти факторы разработчики учитывают при внедрении.
Например, при использовании МТС Exolve разработчик получает доступ ко всем этим материалам и таким инструментам:
управление голосовой связью;
администрирование номеров;
переадресация вызовов;
отправка текстовых сообщений;
отправка голосовых сообщений.
Но, безусловно, важно, чтобы платформа не вызывала страхов у команды, не съедала огромные ресурсы на интеграцию и выступала как основа для индивидуальной разработки и интеграции в корпоративное ПО.
Спасибо за уделенное статье время! Если у вас есть вопросы или вы хотите поделиться своими страхами по поводу коммуникационных API – расскажите об этом в комментариях.