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

Попробуем представить, как же может быть устроен обмен данными между фронтом и сервисами. И начнём мы с каталога товаров. Чтобы представить всю картину целиком, начнём с самого начала: ты, как покупатель, заходишь в интернет-магазин через свой любимый браузер Амиго. Загружаются картиночки, скрипты, HTML-код; рисуются элементы... В этот момент начинает выполняться загруженный скрипт, который обращается к сервису каталога, чтобы получить список товаров (которые, между прочим, на текущий момент ещё не отрисованы).

Допустим, у сервиса каталога будет всего одна ручка, назовём её products. Принимать она будет GET запрос, в теле которого мы будем задавать значение фильтра для товаров... ага, попался, я же говорил, что у GET-запроса нет тела! В общем, конечно же передавать фильтр мы будем не в теле, а в query-параметрах.

Кстати, забыл упомянуть, наш магазин будет продавать мёд и орехи. Мёд липовый и гречишный, а орехи грецкие и фундук. Больше ничего. Соответственно, запрос с фронта будет выглядеть как-то так:
GET /products?item=мёд&type=липовый
или так:
GET /products?item=орех&type=фундук
а может быть даже вот так:
GET /products?item=мёд
или даже так, тоже ничего:
GET /products

В ответ на подобный запрос сервис будет отдавать JSON (и код 200 в заголовках, ведь запрос выполняется успешно, да ведь?). Например, такой:
[{"name": "мёд", "type": "липовый", "price": 450.2}, {"name": "мёд", "type": "гречишный", "price": 650}]

Фронт примет ответ, обработает его и отрисует список товаров, который ты и увидишь в своём любимом браузере. Здорово, правда?

Можно воспользоваться фильтром, его фронт любезно предоставил. Ставим снимаем флажок с мёда, ставим его на орех. Уходит запрос:
GET /products?item=орех

Приходит ответ:
[{"name": "орех", "type": "грецкий", "price": 1000}, {"name": "орех", "type": "фундук", "price": 920}]

И вот, фронт уже удалил мёд и ты видишь орехи. Замечательно! Пойдём до конца, не будем останавливаться на полпути, надо уже купить что-нибудь.

Рядом с каждым орехом фронт отрисовал кнопку "КУПИТЬ", нажимаем на неё. Появляется окошко, в котором надо ввести имя и телефон, а потом нажать кнопку "ОФОРМИТЬ ЗАКАЗ". В этот момент отправляется запрос к другому сервису. У него тоже одна ручка, назовём её checkout. Пусть она принимает запрос типа POST (ведь мы создаём заказ, как же иначе!). В этом типе запросов можно передавать и query-параметры, но мы же всё делаем правильно, поэтому будем передавать данные в теле.

Запрос будет уходить так:
POST /checkout

А в теле может быть что-то подобное:
{"name": "Анаборий Петров", "phone": "+79001234567", "item": "орех фундук"}

В ответ на такое сервис может выдать что-то подобное:
{"status": "ok"}
И код 201 (а может и 200, но у нас крутые разработчики, которые шарят, чем 200 отличается от 201, см. коды ответов HTTP).

Вот таким вот нехитрым образом может быть устроено приложение на микросервисной архитектуре.