Тенденции разработчиков в 2022 году — Демократизация API и управление API

Тенденции, за которыми мы следим

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

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

Где были API

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

API как контракт

API представляет собой контракт между двумя сторонами. Этими двумя сторонами являются поставщик (иногда называемый сервером или издателем) и потребитель (иногда называемый клиентом) службы. API — это согласованный интерфейс (I в API), который обе стороны будут использовать для связи. Этот интерфейс включает условия доступа к API (URL), форматы сообщений, действия, которые могут быть выполнены, и требования безопасности для связи.

Swagger Petstore — классический пример определения API, которое соответствует Спецификации OpenAPI. Каждая конечная точка API имеет четко определенный URL-адрес и метод запроса, а также требования и ожидания в отношении безопасности и формат запросов и ответов.

В современном мире ожидается, что API-интерфейсы будут доступны через стили или протоколы, такие как SOAP или REST. Сегодняшнее использование термина API в первую очередь относится к их использованию в веб-сервисах. Однако несколько десятилетий назад различные компоненты внутри приложения (например, локальное настольное приложение) имели API для облегчения взаимодействия друг с другом.

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

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

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

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

Разработчики как единственные участники разработки API

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

В то время это имело смысл, потому что разработчики были теми, кто создавал API, и, честно говоря, они были единственными, кто понимал, что входит в разработку API.

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

Куда идут API

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

демократизация API

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

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

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

• Удовлетворяет товарные потребности предприятия. Компании не должны продавать товары, за которые покупатели не готовы платить. Точно так же API должны приносить ощутимую пользу компании, положительно влияя на итоговую прибыль.
• Обращается к конкурентной среде, которую он обслуживает. Как и в случае с продуктами, организации, создающие API, должны быть знакомы со своими конкурентами. Какие ценностные предложения предоставляет API? Какой сегмент клиентов охватывает API и как он делает это эффективнее, чем его конкуренты?
• Разработан с расчетом на будущее. Новые технологии появляются быстро. Регулирование конфиденциальности и безопасности данных — движущаяся цель. Потребительские тенденции меняются от одного квартала к другому. Разработан ли API, чтобы противостоять этим изменениям и адаптироваться к ним?

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

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

Разрозненная разработка — это практика прошлого; Демократизация API занимает свое место.

Управление API

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

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

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

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

• Версии
• Среды развертывания
• Места развертывания
• Клиенты (потребители API)
• Показатели использования
• Совместимость
• Отношения с другими API
• Зависимости

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

• Ограничение скорости
• Формирование трафика
• Маскировка данных
• Различные типы аутентификации и т.д.

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

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

Новое поколение инструментов

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

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

Помимо дизайна, шлюз API и консоль управления предоставляют следующие функции:

• Конфигурация политик с малым кодом/без кода с помощью студии политик перетаскивания
• Возможность реализации планов и контрактов API для управления и регулирования потребления.
• Управление документацией по API
• Возможность отправлять API и их документацию на портал разработчиков, ориентированный на потребителя.
• Гибкость для передачи протоколов и подключения синхронных API (т. е. REST API) к асинхронным системам и API (т. е. централизованной серверной части Kafka)

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

Заключение

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

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