Интеграция REST API в микросервисной архитектуре: преимущества модульного подхода и принципы проектирования логических API

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

Модуль или монолит? Подходы в архитектуре цифрового сервиса

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

• план и структура цифрового сервиса (верхнеуровневый);

• решения о том, как проект будет устроена «изнутри»: как будут взаимодействовать части; какие технологии будут применяться;

• набор правил и принципов, которые определяют разработку.

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

Какой бывает архитектура цифровых сервисов? Сейчас популярнее всего деление на два метода: монолитную и микросервисную.

Монолит — это иерархическая архитектура, причем каждый слой приложения отвечает за свою часть функционала: работа с базой, логирование, интерфейс. Как это работает, можно увидеть на примере популярного шаблона Model-View-Controller («Модель-Вид-Контроллер»). Здесь данные приложения и управляющая логика делятся на три отдельных компонента: модель, представление и контроллер.

• Модель — это хранилище данных, которое также реализует логику изменения своего состояния в ответ на запросы контроллера.

• Представление отвечает за визуализацию данных модели для пользователя, автоматически обновляясь при любых изменениях в модели.

• Контроллер выступает посредником между пользователем и моделью, интерпретируя действия пользователя и передавая модели команды на изменение.

Каждый компонент можно изменять независимо от других.

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

Если вы планируете запустить новый онлайн-сервис, начните с архитектуры вместе с экспертами Uplab. Мы разберем ваши бизнес-процессы и устройство системы, предложим, как разделить ее на модули, и опишем API для связи модулей между собой и с внешними сервисами. Напишите нам через форму «Обсудить проект».

API — «чёрный ящик» разработчиков

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

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

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

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

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

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

Мы уже рассказывали подробно об API в одной из предыдущих статей блога и упоминали, что их существует несколько видов. Непосредственно с архитектурой ПО связан REST API (Representational State Transfer).

Как работает REST API

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

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

Representational State Transfer (расшифровка аббревиатуры) чаще всего переводится как «передача состояния представления», но более точно будет перевести это как «передача „самоописываемого“ состояния».

Иногда, помимо русифицированного термина «рест» и акронима REST, можно встретить слово RESTful.

Роль REST API в микросервисной структуре

Итак, РЕСТ АПИ позволяет клиентам (например, веб-приложениям или мобильным приложениям) получать доступ к ресурсам сервера и взаимодействовать с ними через стандартные HTTP-методы (GET, POST, PUT, DELETE) и унифицированный интерфейс, обычно представленный в формате JSON или XML. REST API обеспечивает стандартизированный, гибкий и масштабируемый механизм для взаимодействия этих блоков как внутри программы, так и с внешним миром.

Разделение для удобства и безопасности

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

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

Именно так мы построили работу над сайтом «Фасадные решения». Фронтенд написали на Vue.js, серверную часть на Node.js, а связали их через REST API. Благодаря такому разделению фронтенд и бэкенд разрабатывали параллельно: каждая пара разработчиков отвечала за свою часть, и команды не ждали друг друга.

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

Принципы REST API

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

• Stateless (Без сохранения состояния): каждый запрос от клиента к серверу должен содержать всю необходимую информацию для его обработки. Сервер не хранит информацию о состоянии клиента между запросами.

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

• Единообразие интерфейса.

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

• Code on demand / Код по требованию (опционально): сервер может временно расширить или настроить функциональность клиента, передавая ему исполняемый код (например, JavaScript).

Преимущества модульной архитектуры с применением REST API

1. Масштабируемость и гибкость. Модульная архитектура позволяет масштабировать отдельные модули независимо друг от друга, в зависимости от их нагрузки. REST API поддерживает эту масштабируемость, позволяя развертывать и масштабировать модули как отдельные сервисы. Модульность в сочетании с РЕСТ АПИ делает систему более гибкой к изменениям и новым требованиям. Можно добавлять, изменять или удалять модули, не перестраивая всю систему целиком. Также разработчикам проще понимать и использовать API других модулей, если они соответствуют RESTful принципам.

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

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

Примеры использования

Рассмотрим, как работает подход на примере e-commerce платформы (современного сложного интернет-магазина). В нашем примере разработчики применили микросервисный подход: простыми словами, вместо того, чтобы сложить все в один большой «котёл», разделили систему на независимые модули.

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

• Модуль корзины. Управляет корзиной пользователя, добавлением товаров, расчетом стоимости и т.п. Предоставляет REST API для работы с корзиной.

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

• Модуль доставки. Расчет стоимости доставки, интеграция со службами доставки. REST API для расчета стоимости и отслеживания статуса.

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

Как это всё работает «изнутри»:

1. Фронтенд (веб-сайт или мобильное приложение), когда ему нужно отобразить список товаров, отправляет GET-запрос к REST API модуля каталога.

2. Модуль каталога обрабатывает запрос, получает данные из своей базы данных и возвращает JSON-ответ с информацией о товарах.

3. Фронтенд получает JSON и отображает товары пользователю.

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

Вызовы и сложности

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

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

• Уязвимости безопасности REST API. Если приложение недостаточно защищено из-за отсутствия шифрования, то приложение может раскрыть конфиденциальные данные. API уязвимы для DDoS-атак, что может привести к краху сервера.

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

• Чрезмерный сбор данных и запросы: это особенность систем с REST API, которая ведёт к повышенной нагрузке на сервер.

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

Чтобы система с REST API работала стабильно, важно «перестраховаться»: заложить достаточно ресурсов на регулярные обновления, позаботиться о защите от DDoS-атак и достаточно мощном сервере.

Саммари

• Архитектура программного обеспечения — это верхнеуровневый план и структура цифрового сервиса, а также взаимодействие, правила и принципы внутри него. Существует два основных принципа: монолитная и микросервисная.

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

• REST API (РЕСТ АПИ) — один из популярных API. Это свод правил и принципов, который определяет ограничения для программных интерфейсов. RESTful — смежный термин, означающий «соответствующий REST-подходу».

• РЕСТ АПИ позволяет клиентам получать доступ к ресурсам сервера и взаимодействовать с ними через стандартные протоколы. Модульная структура стремится к изоляции модулей, чтобы изменения в одном минимально влияли на другие. REST API как архитектурный подход обеспечивает эту изоляцию благодаря стандартизации интерфейсов.

• Среди преимуществ РЕСТ АПИ — масштабируемость, свобода выбора решений и методов, а также свобода интеграций. Среди вызовов и сложностей — проблема с управлением большим количеством апи, уязвимости в безопасности, чрезмерный сбор данных и необходимость хорошей документации.