Что значит использовать API-First подход к разработке?

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

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

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

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

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

OpenWeatherMap предлагает приложениям и веб-сайтам гиперлокальные поминутные данные о дожде. Facebook позволяет мобильным разработчикам интегрировать социальные связи и информацию профиля. Список можно продолжить.

Это API, но что такое API-first подход к разработке?

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

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

Основные принципы API-First Development

Поскольку так много разработчиков неправильно (или, возможно, частично правильно) используют термин API-first, может быть трудно понять, какие продукты действительно API-first, а какие нет.

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

1. Ваш API — это продукт

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

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

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

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

2. Фундаментальный дизайн, а не специальная модернизация

API-first дизайн требует, чтобы разработчики думали об API с самого начала. Однако мало кто когда-либо получает работу с чистого листа.

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

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

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

3. Командное сотрудничество и влияние

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

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

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

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

4. API-First поддерживает микросервисы

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

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

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

5. Контракт API

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

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

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

Как API-first соответствует принципам MACH Alliance?

До сих пор мы рассмотрели API и разработку, ориентированную на API. Но ни то, ни другое не существует изолированно. Они находятся в рамках более крупной технологической экосистемы. Вот почему вы часто слышите об API-first наряду с двумя другими понятиями: [архитектура Jamstack] (https://www.gridhaus.com/blog/jamstack-modern-web-architecture-in-digestible-terms) и [MACH Alliance принципы] (https://www.sitecore.com/blog/headless/what-is-mach-architecture).

Например, Jamstack (Javascript, API и разметка) представляет собой набор передовых методов создания современных продуктов. Речь идет о разделении уровня веб-интерфейса и внутренней бизнес-логики. Именно это движение обеспечивает подход MACH.

Но что такое MACH Alliance и какое место занимает API-first? Чтобы ответить на этот вопрос, полезно уменьшить масштаб и спросить: «Кто такой MACH Alliance?»

[Альянс MACH] (https://machalliance.org/about) — это группа независимых технологических компаний, выступающих за открытые, лучшие в своем классе технологические экосистемы. Как и многие, они считают, что корпоративные пакеты устарели, и предлагают заменить их «гибкой и гибкой, всегда актуальной» экосистемой MACH.

Чтобы создать эту экосистему, они советуют компаниям следовать четырем принципам:

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

• API-First: все функции доступны через API.

• Cloud Native: SaaS, использующий облачные ресурсы помимо хранения и хостинга, включая эластичное масштабирование и автоматическое обновление.

• Безголовый: интерфейсная презентация отделена от внутренней логики и каналов, языка программирования и в конечном счете не зависит от фреймворка.

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

Вот почему, когда мы приступили к созданию Algolia, мы следовали принципам MACH, создавая продукты на основе микросервисов, дизайна с приоритетом API, облачной и безголовой архитектуры. Как и другие члены Альянса — BigCommerce, Contentful, MongoDB и AWS среди прочих — мы доказываем, почему этот подход настолько эффективен.

Использовать API в первую очередь непросто, но оно того стоит

Мы раскрыли, что такое разработка с приоритетом API, и изучили некоторые преимущества, которые она дает.

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

Столкнувшись с такими значительными изменениями, неудивительно, что компании останавливаются на полпути или применяют поэтапный подход.

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