1. Введение в REST: Принципы архитектуры и цикл запрос-ответ
Введение в REST: Принципы архитектуры и цикл запрос-ответ
Для Technical Project Manager (TPM) понимание REST API — это не просто знание технического жаргона, а способность говорить на одном языке с командой разработки, корректно формулировать требования к интеграциям и оценивать сложность задач. REST (Representational State Transfer) — это архитектурный стиль, который стал стандартом де-факто для взаимодействия систем в современном вебе.
В этой статье мы разберем фундамент, на котором строятся 90% современных веб-сервисов: клиент-серверную архитектуру, понятие ресурса и принцип stateless.
Что такое REST?
REST — это набор архитектурных принципов для построения распределенных систем. Важно понимать: это не протокол (как HTTP) и не формат данных (как JSON). Это стиль проектирования. Если API соответствует этим принципам, его называют RESTful.
Основная идея REST заключается в том, что взаимодействие между компонентами системы строится вокруг ресурсов, над которыми производятся стандартные операции.
Клиент-серверная архитектура
В основе REST лежит четкое разделение обязанностей между клиентом и сервером. Это разделение позволяет разрабатывать и масштабировать обе стороны независимо друг от друга.
Роли участников
!Базовая схема клиент-серверного взаимодействия
Такое разделение критически важно для TPM. Когда вы ставите задачу на «создание экрана профиля», вы фактически ставите две задачи: одну для фронтенда (клиент: отрисовать форму, отправить запрос), другую для бэкенда (сервер: принять запрос, достать данные из БД, вернуть ответ).
Цикл запрос-ответ (Request-Response Cycle)
Взаимодействие в REST всегда происходит по инициативе клиента. Сервер никогда не отправляет данные сам по себе (без предварительного запроса или использования дополнительных технологий вроде WebSockets). Этот процесс называется циклом запрос-ответ.
Анатомия Запроса (Request)
Когда клиент обращается к серверу, он формирует HTTP-запрос, который состоит из четырех ключевых частей:
GET, POST./users/123.GET запросах тело обычно отсутствует.Анатомия Ответа (Response)
После обработки запроса сервер возвращает ответ, который также имеет структуру:
200 OK, 404 Not Found.Представьте это как заказ в ресторане: * Вы (Клиент) смотрите в меню и говорите официанту: «Хочу стейк» (Запрос). * Кухня (Сервер) готовит блюдо. * Официант приносит вам стейк или говорит, что мясо закончилось (Ответ).
Ресурсы: «R» в REST
Ключевая концепция REST — это Ресурс. Ресурс — это любая информация, которую можно назвать: пользователь, заказ, товар, комментарий.
В RESTful API мы оперируем существительными, а не глаголами. Это фундаментальное отличие от старых подходов (RPC), где вызовы выглядели как действия.
| Подход | Пример URL | Комментарий |
| :--- | :--- | :--- |
| RPC (Action-based) | /getUser?id=42 | URL описывает действие (глагол) |
| REST (Resource-based) | /users/42 | URL описывает объект (существительное) |
Для TPM это важно при проектировании API. Если разработчик предлагает URL вида /createNewOrder, это сигнал о нарушении принципов REST. Правильный подход — использовать метод POST на ресурс /orders.
Принцип Stateless (Отсутствие состояния)
Один из самых сложных для понимания, но важных принципов REST — это Statelessness.
Определение: Сервер не хранит информацию о состоянии сессии клиента между запросами. Каждый запрос от клиента должен содержать всю необходимую информацию для его выполнения.
Как это работает на практике?
Представьте, что вы ведете диалог с человеком, который страдает потерей краткосрочной памяти. Каждую фразу вы должны начинать с полного контекста.
* Stateful (с состоянием): * Клиент: «Привет, я Иван». * Сервер: «Привет, Иван» (запоминает). * Клиент: «Покажи мои заказы». * Сервер: «Вот заказы Ивана» (использует память).
* Stateless (без состояния — REST): * Клиент: «Привет, я Иван». * Сервер: «Привет, Иван» (отдает токен-пропуск). * Клиент: «Покажи мои заказы. Я Иван, вот мой токен». * Сервер: «Вот заказы Ивана» (проверяет токен, не полагаясь на память).
!Различие в хранении контекста между Stateful и Stateless подходами
Зачем это нужно?
Единообразие интерфейса (Uniform Interface)
REST требует, чтобы интерфейс взаимодействия был унифицирован. Это означает, что независимо от того, запрашиваете вы данные о пользователях, товарах или транзакциях, вы используете одни и те же методы и подходы.
Это упрощает интеграцию. Если новый разработчик приходит в команду, и он знает принципы REST, ему не нужно читать тонны документации, чтобы понять, как получить данные. Он интуитивно понимает: чтобы получить ресурс, нужен GET, чтобы создать — POST.
Представление ресурсов (Representation)
Когда клиент запрашивает ресурс /users/42, сервер не отправляет ему физическую запись с жесткого диска. Он отправляет представление этого ресурса. Чаще всего это текстовый формат JSON или XML.
Это позволяет отделить хранение данных от их передачи. В базе данных дата может храниться как число (timestamp), а клиенту отдаваться как строка «2023-10-25». Клиент взаимодействует именно с представлением.