Я долго не могла понять, почему это пример API-driven дизайна. Оказалось, api — это пчёлы

Классический подход к проектированию, существующий с незапамятных времён, — CODE FIRST, в нём разработчики сами устанавливают правила для взаимодействия информационных систем. Подход позволяет быстро получить осязаемый результат в виде запрограммированного куска системы, но есть несколько минусов:

• Первый — возможность получить обратную связь есть только тогда, когда код готов и пользователь может проверить решение, кликая разные кнопочки в GUI. Это часто приводит к тому, что реализованную часть системы приходится писать заново.
• Второй, что хуже — CODE FIRST предполагает каскадную модель разработки: нет возможности настроить параллельно несколько потоков работ.
• Третий недостаток — отсутствие документации и часто слишком детализированное API. Такое API невозможно переиспользовать. 
• И ещё один, четвёртый, минус — отсутствие адаптации к изменениям. А изменения обычно происходят уже во время разработки.

На замену CODE FIRST пришёл подход DESIGN FIRST. Главными героями здесь становятся дизайнеры. Сначала они отрисовывают все макеты, проектируют кликабельные интерфейсы, и только потом, после ревью пользователей, пишется код системы. Это улучшает UX/UI, команда получает обратную связь до того, как продукт будет готов. Но и тут есть очевидные недостатки:

• Дефицит бизнес-навыков и аналитического мышления у дизайнеров.
• Маршруты, положенные в основу архитектуры системы и UI, часто не совпадают с картой бизнес-процессов пользователя. Проще говоря, дизайнер может изобразить любой вариант UI, но возникает вопрос: а можно ли реализовать ту или эту фичу как функционал?
• Ну и та же проблема, как и с CODE FIRST: нет возможностей для быстрой и эффективной адаптации к изменениям. 

И вот тогда, на стыке CODE FIRST и DESIGN FIRST, появился подход API FIRST, который удачно объединил достоинства всех предыдущих методов.

Что такое API

API — это контракт взаимодействия между информационными системами или компонентами одной системы, предмет моего давнего интереса.

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

Первые варианты API появились ещё в 40-х годах прошлого века. А вот сам термин API впервые был применён в своём актуальном значении только на конференции AFIPS в 1968 году. В 70-е термин API фигурирует в статьях о базах данных. Шаг за шагом создаётся то самое API, которое поддерживает не только прикладное, но и другие типы программирования. В 2000-х начинают активно развиваться и применяться первые правила валидации и спецификации API, известные как REST. Развитие технологий привело к появлению около 50 типов API, которые можно подразделить на группы в зависимости от способов взаимодействия и передачи информации: синхронные/асинхронные, звуковые/видео и другие. 

API FIRST. Описание подхода, или Просто о сложном

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

Преимущества

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

Второе преимущество — своевременная проверка — идёт бонусом к первому. Когда пользователь вовремя, быстро и чётко даёт обратную связь, команда не тратит сотни часов на реализацию «тупикового» решения. Ранняя сверка часов и маршрутов позволяет разработчикам быстро двигаться в нужном направлении, экономя силы, время и бюджет. 

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

И четвёртой наградой за доверие аналитикам становится возможность параллельной разработки функционала. 

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

Недостатки

Требуется super-skilled аналитик
Дефицит опыта и скиллов аналитика может привести к тому, что интересы и требования пользователей будут недостаточно учтены. А поскольку именно аналитик отвечает за способы интеграционного взаимодействия и проектирование системы, его квалификация становится критически важной. 

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

Может потребоваться пересмотр инфраструктуры
Если система ранее разрабатывалась по принципу CODE FIRST или DESIGN FIRST, придётся наводить порядок в её архитектуре по новым правилам проектирования. 

Пять «китов», которые поддерживают API FIRST

Самый большой «кит» — это признание API продуктом.
Что это означает? Есть продукт в виде информационной системы, а есть продукт в виде интеграционного взаимодействия и данных, которые включены в систему. И это собрание инструментов и функций в виде программного интерфейса можно рассматривать как отдельный продукт. Существуют маркетплейсы API, где можно приобрести бэкенд-функционал в виде API для построения решений. 

Второй «кит» — релевантный UI-дизайн.
При комбинации API FIRST и DESIGN FIRST роль дизайнеров в разработке возрастает. При подготовке развёртывания системы и интеграционного взаимодействия учёт пожеланий и возможностей обеих сторон ведёт к более быстрому и эффективному решению задач. 

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

Имя четвёртого «кита» — поддержка микросервисов.
Если команда придерживается микросервисной архитектуры проекта, появляется возможность одновременно вести работу над разным функционалом и дизайном. А параллельная разработка нескольких модулей позволяет сокращать время на проекте в разы. 

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

Сравним трудозатраты при разных подходах

У меня была возможность поработать и с CODE FIRST, и с API FIRST в сочетании с DESIGN FIRST и сопоставить и проанализировать трудозатраты в проектах при использовании этих подходов. Опыт показал следующее:



Если на первых этапах кажется, что CODE FIRST вне конкуренции по возможностям быстро «перейти сразу к делу», с минимумом расходов на аналитика, то в процессе работы он явно проигрывает своим соперникам: как только переходим к тестированию и изменениям, CODE FIRST увеличивает трудозатраты примерно в три раза, по сравнению с API FIRST. 

API Сейчас

Почему столько внимания именно API? Потому что это способ договариваться с большими командами.

Внедрение принципа API FIRST привело к бурному развитию рынка API, в том числе и Open API. Сегодня к Open API совершается около 80 млрд вызовов в день. В создание новых API вовлечены девять миллионов разработчиков. Внедрение API приводит к росту капитализации компаний в среднем на 12%. Более 75% крупных банков применяют принцип API FIRST. McKinsey прогнозирует, что количество API в банковском секторе к 2025 году вырастет на 100%. А всего в течение ближайших трёх-пяти лет станут доступны около миллиона Open API.