В предыдущей статье на портале The New Stack, Картик Кришнасвами, руководитель отдела маркетинга продуктов компании NGINX, рассказал, как организации могут заложить основу для создания культуры, ориентированной на API (API-first), и описал этап 1 (видение и оценка). Ниже в продолжение этой темы он представляет этапы 2 (разработка и создание) и 3 (повышение уровня и обучение).

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

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

Этап 2: Разработка и создание

Шаг 5: Создание набора принципов дизайна ваших API

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

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

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

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

Шаг 6: Создание свода правил API

Да, правила — это скучно, но они необходимы. Небрежное проектирование API может создать множество проблем в будущем. Хотя разработчики никогда не ставят перед собой цель создать неаккуратный API, такие факторы, как нехватка времени или требования партнеров, могут негативно повлиять на выбор дизайна. Определите, какие типы API будет поддерживать ваша организация: REST, GraphQL, gRPC или даже SOAP (старая, но все еще полезная структура API при работе с унаследованными системами). Для каждого типа API, который вы решили поддерживать, составьте руководство по стилю, описывающее конкретные критерии проектирования (структура URI, схема и т. д.).

Шаг 7: Настройка инфраструктуры управления и безопасности API

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

Этап 3: Повышение уровня и обучение

Шаг 8: Создание или повышение уровня проектов Lighthouse API

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

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

Шаг 9: Создание программы для амбассадоров и обучения API

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

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

Переход к менталитету API-first

Следование вышеуказанным этапам и шагам увеличит ваши шансы на успех в области API. Главное — использовать целостный и реалистичный подход при переходе от технологии и разработки продукта к мышлению и исполнительной системе API-first. Как и на любом пути внедрения технологий, пряники и поощрения работают лучше, чем кнуты. И, как и при любой другой серьезной смене парадигмы, вам необходимо продумать потребности команд, работающих с API, от разработчиков и DevOps до команд по инфраструктуре и безопасности, которым поручена фиксация API. Никогда не поздно стать компанией API-first и воспользоваться преимуществами перехода к модульному, JTBD-подходу при создании продуктов и функциональности.

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