5. Слои (Layered System)

Архитектура может состоять из нескольких уровней (слоёв). Клиент обычно не знает, взаимодействует ли он напрямую с конечным сервером или с промежуточным (балансировщик, кэш, шлюз).

6. Код по требованию (Code on Demand) — опционально

Сервер может отправлять клиенту исполняемый код (например, JavaScript), расширяя его функциональность.

2.3. Ресурсы и методы http

В REST основная единица — ресурс. Каждый ресурс имеет URI и поддерживает стандартные методы HTTP:

HTTP-метод	CRUD-операция	Пример для ресурса /users
GET	Read (чтение)	GET /users — получить список пользователей; GET /users/123 — получить пользователя с id 123
POST	Create (создание)	POST /users — создать нового пользователя (данные в теле запроса)
PUT	Update (замена)	PUT /users/123 — полностью заменить пользователя с id 123
PATCH	Partial Update (частичное обновление)	PATCH /users/123 — частично обновить пользователя
DELETE	Delete (удаление)	DELETE /users/123 — удалить пользователя

2.5. Преимущества rest

• Простота — использует стандартные HTTP-методы и коды ответа.

• Масштабируемость — за счёт отсутствия состояния и кэширования.

• Надёжность — легче восстанавливаться после сбоев.

• Видимость — запросы содержат всю информацию для понимания.

• Широкая поддержка — любой язык программирования может работать с HTTP.

2.6. Недостатки rest

• Может быть избыточным — для простых операций.

• Сложности с HATEOAS — редко реализуется полностью.

• Не все операции хорошо ложатся на CRUD — например, сложные транзакции.

Часть 3. Микросервисы (Microservices)

3.1. Определение

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

Это противопоставляется монолитной архитектуре, где всё приложение представляет собой единый модуль.

3.2. Характеристики микросервисов

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

2. Одна ответственность — каждый сервис отвечает за одну бизнес-функцию (например, сервис заказов, сервис пользователей, сервис платежей).

3. Независимость — сервисы разрабатываются, тестируются, развёртываются и масштабируются независимо друг от друга.

4. Децентрализация — каждый сервис может использовать свою технологию (язык, БД), наиболее подходящую для его задач.

5. Изолированность — сбой в одном сервисе не должен приводить к падению всей системы.

6. Автоматизация — активное использование CI/CD (непрерывной интеграции и доставки).

7. Слабая связность — сервисы общаются через чётко определённые API (обычно REST или gRPC).

3.3. Коммуникация между микросервисами

• Синхронная — через HTTP/REST или gRPC. Просто, но создаёт зависимость (если сервис недоступен, запрос не выполнится).

• Асинхронная — через очереди сообщений (RabbitMQ, Apache Kafka). Более отказоустойчиво, позволяет сглаживать пиковые нагрузки.