Современная архитектура веб-приложений. Эти ваши микросервисы. Часть 2

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

Давай поподробнее рассмотрим какой-нибудь сервис (не важно какой, пусть будет абстрактный). Как у тебя для взаимодействия с окружающим миром есть глаза, уши, рот и другие части тела (гусары, молчать!), так и у сервиса должны быть какие-то способы общения. Чаще всего для организации такого взаимодействия используется REST-архитектура. Такая архитектура предполагает наличие у сервера определённого API, по которому с ним можно взаимодействовать. API - программный интерфейс, который может использовать кто угодно для взаимодействия с сервисом.

Ну эти термины, скажем проще, сервис имеет ручки (arms, endpoints), которые можно дёргать (отправлять на них запросы) для достижения желаемого результата. Обычно, эти самые ручки являются ничем иным как путями в URL, запросы на них отправляются HTTP-протоколом, данные уходят в теле (для POST, PUT) или в URL (для GET, DELETE). В общем, ты понял.

Итак, что имеем. У нас есть сервис каталога, который поддерживает единственный запрос типа GET для получение всех карточек; у нас есть сервис корзины, который поддерживает единственный запрос типа POST для создания заказа пользователя. И ещё, у нас есть фронт, который возвращается браузеру GET-запросом, и который дёргает ручки других сервисов для осуществления желаемых действий.