Заглядывая в будущее экономики API

Заглядывая в будущее экономики API

Источник · Перевод автора

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

API становятся частью интернет-структуры

Для некоторых студентов, изучающих современную технологическую историю, «связная» часть Интернета выглядела совсем иначе всего несколько десятилетий назад. Под «связью» я имею в виду API-интерфейсы, такие протоколы, как HTTP, и согласованные архитектурные шаблоны, которые открывают доступ к данным. В результате технологические профессионалы говорят о проектах «устаревшей модернизации», чтобы выявить старые технологические разрозненные хранилища, которые в противном случае остались бы скрытыми от цифровой жизненной силы бизнеса. Эти так называемые проекты цифровой трансформации часто полагались на XML-RPC для обеспечения интеграции с мэйнфреймами, в то время как новая цифровая эра принесла такие стандарты, как REST, GraphQL и Web of Things.

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

У этой тенденции есть два интересных следствия. Во-первых, все это вызывает потребность в лучших, более быстрых и простых для понимания API. Многие производители платформы интеграции как услуги (iPaaS) прекрасно это понимают. Установленные решения iPaaS, такие как решения Microsoft, MuleSoft и Oracle, постоянно совершенствуются новыми инструментами, в то время как новые участники, такие как Zapier и Workato, продолжают появляться. Все вкладываются в упрощение интеграции поверх API-интерфейсов, что существенно сокращает время интеграции (уровень, который становится все более важным, когда речь идет о гибкости бизнеса). Некоторые называют эти возможности «соединителями», а другие – «шаблонами». Но, в конце концов, в эту область активно вкладываются ведущие интеграционные умы.

Второе следствие – четко определенная связь на основе протокола. Глядя на мир REST – общепринятого архитектурного стиля, определенного в диссертации Роя Филдинга, – мы видим, что REST API доминируют на сцене с устоявшимися стандартами спецификаций, такими как спецификация OpenAPI (ранее известная как Swagger). Эти протоколы не только позволяют ведущим в отрасли решениям iPaaS прийти к соглашению о том, как будет выглядеть следующий мир подключений, но и закладывают основу для развития новых возможностей – часто называемых инновациями. Постоянно появляется все больше технологий, предлагающих продукты для визуализации и преобразования, которые понимают эти стандарты, в то же время привлекая больше пользователей в мир связи.

Я в восторге от потенциала этого пространства и его способности определять фундаментальные строительные блоки будущего Интернета с API в качестве центрального элемента его структуры.

Устранение разрозненности с помощью индексированного поиска и обнаружения API в браузере

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

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

Вторая форма включает в себя то, как мы исследуем эти API и данные, которые они содержат. Сегодня многие разработчики начинают с поиска портала API, поиска соответствующего SDK и тестирования возможностей API с помощью инструментов потребления API, таких как Postman. Однако менее технические пользователи обращаются к решениям с низким кодом / без кода, которые устраняют технический пробел, демистифицируя доступ к API (навык, обычно предназначенный для разработчиков программного обеспечения). Интересно подумать о том, что изменится по мере развития базовой основы этих протоколов и стандартов. Я считаю, что скоро мы увидим больше браузерных инструментов обнаружения, в которых веб-страницы заменяются конечными точками, а информация заменяется данными. В этом мире пользователи могут искать, запрашивать, воспроизводить и вставлять данные вместо того, чтобы беспокоиться о технических особенностях API, таких как URI, синтаксис конечных точек, параметры запроса и т. д.

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

Создание возможностей подключения: протоколы или подключение как услуга

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

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

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

Данные – новая конечная точка в безопасности

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

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

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

Суть

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