Gymterview
junior

Какие ограничения (constraints) определяет REST?

REST определяет шесть архитектурных ограничений, пять из которых обязательны и одно опциональное:

  1. Клиент-сервер (Client-Server) — разделение ответственности: клиент отвечает за пользовательский интерфейс, сервер — за хранение и обработку данных. Это позволяет независимо развивать клиентскую и серверную части.

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

    • упрощается масштабирование (любой сервер может обработать любой запрос);
    • повышается надёжность;
    • упрощается мониторинг.
  3. Кэширование (Cacheable) — ответы сервера должны явно или неявно указывать, могут ли они быть кэшированы. Правильное кэширование снижает нагрузку на сервер и улучшает производительность клиента.

  4. Единообразие интерфейса (Uniform Interface) — ключевое ограничение REST, включающее четыре подпринципа:

    • Идентификация ресурсов — каждый ресурс идентифицируется через URI.
    • Манипуляция ресурсами через представления — клиент работает с представлениями ресурсов (JSON, XML), а не с самими ресурсами напрямую.
    • Самоописательные сообщения — каждое сообщение содержит достаточно информации для его обработки (Content-Type, метод, заголовки).
    • HATEOAS (Hypermedia as the Engine of Application State) — клиент взаимодействует с приложением полностью через гипермедиа, предоставляемую сервером.
  5. Многоуровневая система (Layered System) — архитектура может состоять из нескольких уровней (прокси, балансировщики, шлюзы). Клиент не знает, взаимодействует ли он напрямую с сервером или с промежуточным уровнем.

  6. Код по требованию (Code on Demand) — опционально — сервер может расширять функциональность клиента, передавая исполняемый код (например, JavaScript). Это единственное опциональное ограничение.

На собеседовании: нужно перечислить все шесть ограничений и отметить, что Code on Demand — опциональное. Частая ошибка — забыть про Uniform Interface или не раскрыть его четыре подпринципа.