Потрясающее количество интернет-трафика-в диапазоне 70-80%, в зависимости от того, чьи данные вы считаете-поступает от вызовов API.
Но в то время как 85% разработчиков сообщают о создании или поддержании RESTFUL API, только около 50% опрошенных DEV говорят, что они используют спецификации OpenAPI, согласно данным 2023 года от Postman, компании API платформы.
Что это значит? Многие красные флаги, по словам Мэтью Фогет, вице -президента инженеров Ambassador.
«У нас слишком много API и недостаточно характеристик», — сказал Фогет в презентации в прошлый четверг в Апидайс Нью -Йорк.
Добавьте к этой ситуации появление протокола контекста модели (MCP), стандарта с открытым исходным кодом, целью которого является оптимизация того, как взаимодействуют модели ИИ и API. Он отметил, что аналитическая фирма Gartner «сообщила, что 80% фреймворков агента AI Enterprise будут использовать стиль Service Discovery с боковым стилем MCP к 2028 году.
«Так что добавьте в это такой третий слой, что вы получаете?» Фогет спросил. «У вас есть много API, много трафика в Интернете, выполненном с помощью API, и, возможно, много агентов ИИ, использующих эти API».
По словам Фогет, с наводнением агентов ИИ, использующих эти API, в которых отсутствуют стандартизированные характеристики, поднимается «еще больший красный флаг». «Откуда вы узнаете, к каким типам данных доступ к этим агентам AI, если у вас нет высококачественных спецификаций API, чтобы рассказать вам, как это взаимодействие ведет?»
Нынешняя ситуация сводится к двум основным проблемам, сказал он: отсутствие спецификаций API и недостаточных петлей для развития. Чтобы помочь разработчикам преодолеть эти препятствия, Voget предложил аудитории Apidays пять «чит -кодов» для создания лучших API в эпоху агентов ИИ.
Отсутствующие спецификации, циклы развития
Фогет предложил, что строительство API без спецификаций OpenAPI может сдержать организации от полного использования агентов ИИ и связанных с ними инноваций.
«Я уже видел здесь полдюжины компаний, в которых говорилось, что они преобразуют ваши открытые спецификации API в серверы MCP», — сказал он. «Вы не можете сделать это, если у вас нет открытой спецификации API».
И эти отсутствующие спецификации API, по словам Фогета, могут представлять другие, более потенциально опасные уязвимости, чем просто упустить последнюю и лучшую. «Вы можете столкнуться с ошибками из -за непроверенного кода или неиспользованных API. У вас могут быть проблемы с интеграцией между вашими API».
По его словам, пробелы в безопасности также являются большой проблемой в таких случаях. «Вы можете не знать, что API защищен или не защищен, если у вас нет его описания в спецификации и бедно [developer experience]Полем Это верно не только для людей, взаимодействующих с вашими API, но и для агентов ИИ ».
По словам Фогет, процесс, посредством которого API проходят при разработке, также могут представлять проблемы.
Он представил модель для разработки программного обеспечения с «внешними» и «внутренними» петлями. «Внутренняя петля, о которой вы можете придумать, — это то, что разработчику придется делать несколько раз в день, когда, возможно, создать новый API или создавать функцию», — сказал Фогет. «Они будут писать код, они будут создавать его, они будут проверять свой код локально. Как правило, они отлаживают, а затем, наконец, совершают.
«А затем это введет во внешний цикл, где они будут делать такие вещи, как запустить рабочий процесс CI, выполнять тестирование интеграции и развертывание, в конечном итоге, для производства. И поэтому, если вы подумаете об этом, внутренняя цикл должна быть действительно быстро, потому что разработчики будут выполнять это несколько раз. Они будут быстро валидацию, особенно если они используют инструменты генерации кода AI».
Но эта модель для разработки программного обеспечения требует компромиссов, которые влияют на производительность разработчиков, добавил он: скорость в зависимости от качества, автономия и навыки.
«Иногда трудно найти того, что единорогово -разработчик, который может сделать все это», — сказал он. В результате «мы часто называем эти команды. У нас есть команда DevOps или платформ, а затем у нас есть наши функциональные команды разработчиков, но эти команды SILED могут привести к неэффективности, особенно когда разработчику нужно что -то развернуть в размещенной среде или отдаленной среде, чтобы что -то проверить».
Чит -коды для API
Чтобы помочь преодолеть проблемы пропущенных спецификаций и неэффективных циклов развития, Voget предложил пять «чит -кодов» для создания лучших API.
1. Используйте AI-управляемые спецификации.
Используйте ИИ для того, что ИИ хорош в: Следующие правила.
«Я еще не доверяю ИИ, чтобы написать весь свой код и ожидать, что этот код будет свободным от ошибок»,-сказал Фогет. Тем не менее, «где я бы доверил, что контент, сгенерированный AI, больше следует за жесткой структурой, такой как спецификация API Open, и скажут:« Эй, используйте сопоставление шаблонов и заполняйте пробелы, которые у меня есть в этой спецификации », или« создать эту спецификацию для меня на основе сканирования моих кодовых файлов и привлечь меня к этой спецификации ».
2. Основыте свои макеты на спецификациях API.
По словам Фогет, если ИИ позволяет разработчикам быстрее создавать спецификации API более качественного API, они также должны быть в состоянии быстрее раскручивать макетные экземпляры этих спецификаций API.
«Мик -серверы действительно полезны для питания параллельной разработки», — сказал он. «Может быть, у вас есть команда фронта, которая работает над пользовательским интерфейсом и бэкэнд-командой, которая работает над API. Они могут работать параллельно, если у них действительно высококачественный макет, который описывает этот интерфейс. И поэтому мне нравится основываться на этих макетах из спецификаций, в отличие от выпуска реализаций макетных серверов, потому что они трудно поддерживать».
3. Примите тестирование рабочего процесса.
«У нас, особенно с микросервисами, куча API, которые занимаются специализированными вещами или имеют несколько конечных точек», — сказал Фогет. «И мы можем настроить эти контрактные тесты для проверки единиц нашего API. Но что действительно круто, так это то, что Open API имеет спецификацию Arazzo… спецификации Arazzo действительно великолепны, потому что они могут проверить рабочий процесс вызовов API».
Спецификация Arazzo может помочь пройти функциональный тест рабочего процесса API, сказал он. Например, «допустим, что у меня есть API для получения профиля пользователя, но сначала мне нужно аутентифицировать, чтобы получить токен Auth. Так что это вызов API. И тогда, возможно, мне нужно получить список пользователей. Так что это еще один вызов API. И тогда я наконец могу получить профиль пользователя по ID, который является третьим вызовом API».
Спецификация Arazzo, по словам Фогет, «может описать все это взаимодействие, которое действительно, действительно мощно. Если мы придем к спецификациям Arazzo, мы можем настроить эти сквозные тесты и интеграционные тесты на основе этих спецификаций».
4. Разработайте локально, но тестируйте удаленно.
По словам Фогет, первые три чит -коды направлены на решение проблемы отсутствия или неадекватных характеристик. Последние две проблемы с петлей разработки/разработчика. Проблемы производительности.
В результате чит -кода № 4: Вы говорите, что что -то работает на вашей машине? Докажите это.
«Как мы можем перенести тестирование из нашей внешней петли Dev в нашу внутреннюю петлю Dev, где он быстро?» Фогет спросил. «То, что мы можем сделать, это настроить эту концепцию удаленной общей среды разработки».
Некоторые разработчики, возможно, уже создали среды эфемерных испытаний в своем рабочем процессе CI, он сказал: «Где вы можете кодировать что -то, и вы отправляете запрос на притяжение, а затем мы раскручиваем какую -то удаленную среду, чтобы провести тестирование».
Но Фогет думает, что «мы можем изменить это даже дальше влево, и уже создана среда разработки, чтобы вам потребовалось только внести изменения в код API и запустить и тестировать только ваш API при тестировании с помощью удаленных ресурсов, таких как ваш пользовательский интерфейс или другие зависимости. Издевательные услуги могут действительно помочь с этим, особенно если вы хостируете, адельные экземпляры».
По его словам, создав общую, удаленную среду разработки, команда может облегчить «бремя управления всем вашим приложением на местном уровне».
Ключевое слово, как предложил Voget, является «общим»: «Больше не запускаю все на местных хостах, где только вы можете получить к нему доступ. Имейте эти общие, излечимые URL -адреса, которые вы можете отдать своей командой сказать:« Эй, проверьте мои локальные изменения »или« проверить мои изменения, которые я подталкиваю к этой общей среде разработки », опередив меня, что я заканчиваю код или подтолкну его к CI -горизонам».
5. Используйте производственные среды разработки.
«Если мы создаем эту общую среду удаленного развития, то самое приятное в этом, мы можем сделать это настолько близким к производству, насколько хочется», — сказал Фогет. «Это отдаленно. Скорее всего, он будет построен в той же инфраструктуре и архитектуре, что и в нашей производственной среде».
Он отметил, что стационарная или предварительная среда, которая тщательно имитирует производственную среду, является идеальной средой, является; Так почему бы не создать среду разработки, которая также имитирует среду Prod?
Среда DEV-качества должна включать в себя шлюз по производству API, а также «все микросервисы и все зависимости, которые нам необходимы для запуска наше полное применение»,-сказал Фогет. «Мы можем получить это действительно качественное тестирование, прежде чем мы даже совершили наш код».
Чит-код № 5, по его словам, помогает решить компромисс API-строителей-и разработчиков в целом-лицо, между качеством и скоростью. «На самом деле у нас есть и то, и другое», — сказал он. «У нас может быть быстрый Dev Loop, внутренняя петля Dev, а также иметь высококачественную тестовую среду, чтобы проверить наши изменения в нем».
Hasura облегчает доступ к данным, мгновенно сочиняя API GraphQL, который поддерживается базами данных и услугами, чтобы команда разработчиков (или потребители API) стала немедленно продуктивной. Природа самого GraphQL и динамический подход Hasura облегчают интеграцию и итерацию. Узнайте больше последних из Hasura Trending Stories YouTube.com/thenewstack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Хизер Джослин является главным редактором нового стека, с особым интересом к вопросам управления и карьеры, которые имеют отношение к разработчикам и инженерам программного обеспечения. Ранее она работала главным редактором контейнерных решений, облачного консалтинга … Подробнее от Хизер Жослин
