Введение
Когда мы только начинали работать с API, они представляли собой внутренние инструменты, похожие на связующий код между сервисами, обёртки для бизнес-логики или конечные точки, запрятанные глубоко в инженерной документации. Они были хрупкими, недокументированными и сложными для совместного использования. Перенесёмся в настоящее время, и мы наблюдаем переломный момент: команды либо модернизируют API для поддержки собственных сценариев использования ИИ, либо испытывают трудности с модернизацией в мире, который уже вышел за рамки взаимодействия API исключительно с человеком.
В отчете об API этого года отмечен поворотный момент: API больше не просто поддерживают приложения; они поддерживают агентов.
Чтобы понять, как эти изменения меняют опыт разработчиков, стратегию продукта и операционные модели, мы опросили более 5700 разработчиков, архитекторов и руководителей по всему миру.
Получен четкий сигнал: стратегия API быстро становится стратегией ИИ.
Разработка API-решений ускоряется на 12% по сравнению с прошлым годом
В течение многих лет концепция API-first была многообещающей: рассматривая API как продукты, а не как проекты, организации могли бы получить существенную выгоду от разработки, масштабирования и монетизации своих цифровых предложений.
Сегодня данные ясно показывают: переход от подхода «сначала код» к подходу «сначала API» не просто происходит, он ускоряется.
Восемьдесят два процента организаций в той или иной степени приняли подход, ориентированный на API, а 25% работают как организации, полностью ориентированные на API, что на 12% больше, чем в 2024 году. Это весомый сигнал о том, что API больше не рассматриваются как побочные продукты проектирования, а как долговечные продукты, которые являются основой для внедрения агентов ИИ.
Этот сдвиг отражает то, что мы видели на собственном опыте: когда API рассматриваются как долгосрочные продукты с дорожными картами, циклами обратной связи и соглашениями об уровне обслуживания (SLA), они раскрывают возможности масштабирования, недоступные абстракциям на уровне кода. Вместо нестабильных передач и многократного переписывания, команды начинают проектировать с учётом повторного использования.
И это не только техническая, но и организационная трансформация. Команды, полностью ориентированные на API, часто на ранних этапах координируют разработку продукта и разработку, встраивают управление в рабочие процессы и продумывают, как API будут использоваться как людьми, так и машинами, как внутри компании, так и за её пределами.
Разработка API является глобальной и асинхронной
API-интерфейсы являются основополагающей и критически важной работой для разработчиков: 69% из них тратят более 10 часов в неделю на задачи, связанные с API, что делает их значительной частью своей профессиональной деятельности.
Работа по-настоящему глобальна: 43% находятся в Азиатско-Тихоокеанском регионе, а 30% — в Северной Америке, что создаёт распределённую рабочую силу, охватывающую все часовые пояса. Когда инженеры среднего звена на разных континентах выполняют большую часть работы с API, практика написания только кода может дать сбой. Необходимы общие, воспроизводимые артефакты, чтобы любой мог безопасно поставлять решения без специальных знаний.
Работа, связанная с API, требует прочной основы
Наиболее распространенные действия API показывают, почему координация так важна:
-
Тестирование (81%):
проверка поведения API и контрактов
-
Разработка (73%):
написание и поддержка реализаций API
-
Документирование (58%):
создание и обновление спецификаций API
Поскольку распределённые команды тратят значительное время на тестирование, разработку и документирование, большинство изменений происходят асинхронно. Эта реальность делает следующие тенденции ещё более важными, поскольку практики, эффективные для коллективно работающих команд, создающих простые приложения, неэффективны при применении к глобальным командам, создающим сложные экосистемы API.
Понимание того, кто работает с API, помогает понять, почему наблюдаемые нами тенденции так важны. Когда большую часть работы с API выполняют инженеры, разбросанные по часовым поясам, проблемы, связанные с внедрением ИИ, безопасностью, совместной работой и стандартизацией, становятся ещё сложнее. Давайте рассмотрим, как эти глобальные команды справляются с пятью критическими изменениями в ландшафте API.
Многие разработчики по-прежнему исходят из человеческого фактора, что создает фундаментальное несоответствие между тем, как создается программное обеспечение, тем, как оно проектируется и для кого оно проектируется.
Респонденты полагаются на ИИ для улучшения качества кода (68%), создания документации API (41%) и ускорения циклов разработки.
Однако столь широкое внедрение ИИ выявляет существенный пробел: хотя разработчики создают продукты с использованием ИИ, большинство API не рассчитаны на использование ИИ.
Только 24% разработчиков активно разрабатывают API с учётом ИИ-агентов. Анализ показывает осторожный подход отрасли:
- 13% проектируют одинаково для людей и агентов ИИ
- 7% в первую очередь предназначены для использования агентами ИИ/машинами
- 5% активно переходят от проектирования, ориентированного на человека, к проектированию, ориентированному на ИИ
Между тем, 60% по-прежнему разрабатывают приложения, ориентированные в первую очередь на людей, а 16% пока даже не рассматривают агентов ИИ в качестве потребителей API.
Это несоответствие имеет реальные последствия. Большая часть вашего кода интеграции теперь пишется или поддерживается ИИ. Агенты ИИ полагаются на точные, машиночитаемые сигналы, а не на знание, основанное на опыте. Если в вашем API отсутствуют предсказуемые схемы, ошибки при типизации и чёткие правила поведения, агенты ИИ не могут функционировать так, как задумано.
Оригинальная статья взята с сайта:
