Унифицированный API: устранение разрыва между SaaS-приложениями

Унифицированный интерфейс прикладного программирования (API) — это API, который служит уровнем абстракции, который может одновременно взаимодействовать с несколькими базовыми API.

В результате каждый объект и конечная точка в унифицированном API сопоставляются с соответствующим объектом и конечной точкой в ​​базовом API . Это позволяет SaaS-компаниям создать единую интеграцию с унифицированным API и мгновенно реализовать интеграцию с каждым из базовых API.

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

Какую проблему решают унифицированные API?

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

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

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

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

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

Как работают унифицированные API?

Давайте рассмотрим, как работает унифицированный API, на наглядном примере.

Представьте, что ваши клиенты просят интегрировать ваш продукт с их CRM — среди вашей пользовательской базы одни клиенты используют Salesforce, другие — HubSpot, а некоторые — Dynamics или Pipedrive.

Унифицированный API CRM будет абстрагировать API каждого из этих CRM, сохраняя ссылки на API каждого из базовых CRM.

Источник: Парагон

В приведенном здесь примере показано, что каждая базовая CRM имеет объект, представляющий «контакт».

HubSpot называет его контактом, Salesforce предоставляет как объект интереса, так и контакт, а Pipedrive называет контакты потенциальными клиентами. Когда выполняется вызов объекта «Контакт» в рамках единого API, унифицированный API затем ссылается на соответствующий объект в указанной службе.

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

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

Единые API для конкретных категорий

Не все API можно объединить в одном API, поскольку разные приложения SaaS имеют уникальные модели, структуры и функции данных.

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

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

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

Каковы преимущества унифицированных API?

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

Абстракции API

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

Это не только упрощает и ускоряет создание таких интеграций, но также помогает снизить сложность интеграций.

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

Управляемая аутентификация

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

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

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

Ведение журнала

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

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

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

Готовый пользовательский интерфейс

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

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

Каковы проблемы с использованием унифицированных API?

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

Ограничения вариантов использования

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

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

Источник: Парагон

Давайте рассмотрим некоторые примеры этих ограничений.

Несовместимые черты

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

Например, предположим, что вы хотите интегрироваться с несколькими инструментами обратной связи с клиентами через «унифицированный API обратной связи». Если один инструмент использует количественную модель с оценкой обратной связи от 1 до 10, тогда как другой собирает только «отрицательные, нейтральные, положительные» с «примечаниями», унифицированный API не сможет поддерживать эти варианты использования, поскольку вы не можете согласовать их. их в одну ссылку.

Отсутствующие поля

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

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

Пользовательские объекты и поля

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

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

Ограничения ставок

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

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

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

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

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

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

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

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

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

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

Упрямая модель данных

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

Ограничения дорожной карты

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

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

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

Когда следует использовать единый API

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

Если вы не можете с уверенностью ответить «да» на четыре пункта выше, возможно, вы не захотите использовать единый API.

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

Задача интеграции B2B SaaS

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

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

Это развивающийся рынок со множеством новых игроков, и это, безусловно, интересный подход к решению проблемы интеграции B2B SaaS.

Узнайте все об API, их преимуществах, проблемах и вариантах использования в подробном руководстве.