1.2. Архитектурный стиль rest

REST (Representational State Transfer) – это архитектурный стиль, описанный Роем Филдингом в 2000 году [1]. В отличие от SOAP, REST не является протоколом и не имеет официального стандарта W3C. Это набор ограничений и рекомендаций для построения масштабируемых систем.

Шесть ограничений REST:

Для того чтобы система считалась RESTful, она должна удовлетворять следующим принципам:

1. Клиент-Сервер (Client-Server): Разделение ответственности. Сервер занимается хранением данных, клиент – интерфейсом.

2. Отсутствие состояния (Stateless): Сервер не хранит информацию о состоянии сессии клиента между запросами. Каждый запрос должен содержать всю необходимую информацию для его обработки.

3. Кэшируемость (Cacheable): Ответы сервера должны быть явно помечены как кэшируемые или некэшируемые.

4. Единообразие интерфейса (Uniform Interface): Унифицированный способ обращения к ресурсам (обычно через URI) и использование стандартных методов HTTP.

5. Слоистая система (Layered System): Клиент не знает, общается ли он напрямую с сервером или через промежуточные узлы (балансировщики, прокси).

6. Код по требованию (Code on Demand): (Опционально) Сервер может передавать исполняемый код (например, скрипты JS) клиенту.

Ресурсы и методы HTTP

В REST ключевой абстракцией является «Ресурс». Каждая сущность (например, «Студент») имеет свой уникальный идентификатор (URI). Манипуляции с ресурсами производятся с помощью стандартных HTTP-методов, которые семантически соответствуют CRUD-операциям [4]:

• GET: Получение представления ресурса (безопасный и идемпотентный метод).

• POST: Создание нового ресурса.

• PUT / PATCH: Полное или частичное обновление ресурса.

• DELETE: Удаление ресурса.

При проектировании RESTful систем критически важными являются понятия идемпотентности и уровней зрелости API.

Идемпотентность методов

Свойство идемпотентности означает, что многократный повторный вызов одного и того же метода с теми же параметрами приведет к тому же состоянию сервера, что и однократный вызов.

• Методы GET, PUT, DELETE являются идемпотентными. Например, повторная отправка запроса DELETE /students/1 не приведет к ошибке логики: если студент удален, он останется удаленным. Это свойство критически важно для надежности сетевого взаимодействия: если клиент не получил ответ из-за сбоя сети, он может безопасно повторить идемпотентный запрос.

• Метод POST не является идемпотентным. Повторная отправка POST-запроса может привести к созданию дубликата ресурса.

HATEOAS и Модель зрелости Ричардсона [6]

Вершиной развития REST-архитектуры (Уровень 3 по модели Ричардсона) является принцип HATEOAS (Hypermedia as the Engine of Application State). Согласно этому принципу, клиент взаимодействует с приложением исключительно через гипермедиа, предоставляемую сервером. В ответе сервера, помимо данных, содержатся ссылки (links) на возможные следующие действия. Это снижает связность (coupling) между клиентом и сервером, так как логика переходов диктуется сервером динамически.