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

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

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

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

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

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

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

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

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

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

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

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

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

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-архитектуре».

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

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

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

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

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

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

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

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

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

3. Свобода интеграций. REST API не только связывает модули внутри программы, но и позволяет предоставлять её функциональность внешним клиентам и другим системам. Модульная архитектура, построенная на 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-атак и достаточно мощном сервере.

Саммари

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

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

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

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

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