Java Interview Questions

Главная / Все ответы / REST HTTP

Вопрос 1 · Раздел 6

Что такое REST?

Это не протокол и не библиотека, а набор рекомендаций (constraints). Сервис можно назвать RESTful, только если он следует всем этим рекомендациям.

Russian REST HTTP Исходный Markdown
Версии по языкам: English Russian Ukrainian

Junior Level

REST (Representational State Transfer) — это архитектурный стиль для построения веб-сервисов, предложенный Роем Филдингом в 2000 году.

Это не протокол и не библиотека, а набор рекомендаций (constraints). Сервис можно назвать RESTful, только если он следует всем этим рекомендациям.

Основные принципы:

  • Ресурсы: Всё в REST является ресурсом, идентифицируемым через URI (например, /users/1).
  • HTTP методы: Используются стандартные методы HTTP для операций над ресурсами:
    • GET — получение данных
    • POST — создание данных
    • PUT — обновление данных
    • DELETE — удаление данных
  • Stateless: Каждый запрос содержит всю необходимую информацию. Сервер не хранит состояние клиента между запросами.
  • Формат данных: Обычно используется JSON или XML.

Пример REST API:

GET    /users        — получить всех пользователей
GET    /users/1      — получить пользователя с ID 1
POST   /users        — создать нового пользователя
PUT    /users/1      — обновить пользователя с ID 1
DELETE /users/1      — удалить пользователя с ID 1

// Обратите внимание: ресурс назван во множественном числе (/users), // а конкретный экземпляр — через /users/{id}. Это стандартная конвенция.

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

  1. Client-Server — разделение ответственности между клиентом и сервером
  2. Stateless — каждый запрос независим
  3. Cacheable — ответы можно кэшировать
  4. Layered System — клиент не знает о промежуточных слоях (прокси, CDN)
  5. Uniform Interface — единообразие интерфейса: любой ресурс доступен через одинаковый набор операций (GET/PUT/POST/DELETE), независимо от того, что это за ресурс.
  6. Code on Demand (опционально) — сервер может передавать исполняемый код

Когда НЕ использовать REST

  1. High-frequency real-time streaming — лучше WebSockets или gRPC streams
  2. Внутренние микросервисы с жёсткими latency-требованиями — лучше gRPC (бинарный, быстрее сериализация)
  3. Сложные графовые запросы — лучше GraphQL (один запрос вместо N REST calls)

Middle Level

REST vs RESTful

  • REST — это архитектурный стиль
  • RESTful — конкретная реализация API, придерживающаяся REST-стиля
  • Большинство “REST API” на самом деле являются HTTP API, так как игнорируют HATEOAS

HTTP API использует HTTP как транспорт, но может игнорировать REST-ограничения (например, не использовать HATEOAS или нарушать идемпотентность). RESTful API следует всем 6 ограничениям.

Richardson Maturity Model

  • Level 0: HTTP как транспорт (RPC через HTTP)
  • Level 1: Использование ресурсов (отдельные URI)
  • Level 2: HTTP методы и статус-коды (стандарт индустрии)
  • Level 3: HATEOAS (гипермедиа как двигатель состояния приложения)

Content Negotiation

Сервер и клиент договариваются о формате данных через заголовки:

  • Content-Type: application/json — формат отправляемых данных
  • Accept: application/json — формат ожидаемых данных

Vary Header

Заголовок Vary указывает, какие заголовки запроса влияют на ответ:

Vary: Accept-Encoding, Authorization

Неправильная настройка может привести к проблемам с кэшированием.

Senior Level

Архитектурные нюансы

Проблема HATEOAS в микросервисах

HATEOAS требует, чтобы сервер возвращал ссылки на связанные действия. В микросервисах это становится проблемой:

  • Микросервис не знает внешнего URL API Gateway
  • Решение: Использование заголовков X-Forwarded-Host или специальных библиотек (Spring HATEOAS)

URI Length Limit

Стандарт не ограничивает длину URI, но большинство серверов и прокси (Nginx, AWS ALB) ограничивают её до 8КБ. Если передаёте огромные фильтры в GET-запросе, можно получить 414 URI Too Long.

HTTP Method Tunneling

Если корпоративный файрвол блокирует PUT/DELETE, используется X-HTTP-Method-Override: DELETE внутри POST-запроса.

Производительность и Highload

  • Thundering Herd Problem: При истечении кэша популярного ресурса тысячи запросов могут одновременно ударить в БД
    • Решение: “Soft expiry” или блокировки на уровне кеширующего слоя (Redis/Memcached)
  • Binary Format: Для мобильных клиентов или высоконагруженных систем REST может отдавать MessagePack или CBOR, сохраняя семантику HTTP

Modernity (Java 21 / Spring Boot 3.3)

  • Virtual Threads (Project Loom): REST-контроллеры могут обрабатывать десятки тысяч соединений без WebFlux (начиная с Java 21, 2023; до этого reactive стеки были единственным способом обрабатывать десятки тысяч соединений)
  • HTTP/3 (QUIC): Устраняет Head-of-Line blocking на уровне TCP
  • Declarative Clients: @HttpExchange позволяет описать контракт API в интерфейсе
  • Problem Details (RFC 9457): Стандартный JSON с полями type, title, status, detail, instance для обработки ошибок

🎯 Шпаргалка для интервью

Обязательно знать:

  • REST — архитектурный стиль, предложенный Роем Филдингом в 2000 году, а не протокол
  • 6 ограничений REST: Client-Server, Stateless, Cacheable, Layered System, Uniform Interface, Code on Demand
  • RESTful API следует всем 6 ограничениям; большинство «REST API» — это просто HTTP API без HATEOAS
  • Richardson Maturity Model: Level 0–3, где Level 2 (HTTP Verbs + Status Codes) — золотой стандарт индустрии
  • REST не подходит для real-time streaming (лучше WebSockets/gRPC) и сложных графовых запросов (лучше GraphQL)
  • Content Negotiation работает через заголовки Content-Type и Accept
  • HTTP/3 (QUIC) устраняет Head-of-Line blocking на уровне TCP
  • Virtual Threads в Java 21 позволяют обрабатывать десятки тысяч соединений без reactive-стека

Частые уточняющие вопросы:

  • В чём разница между REST и RESTful? — REST — стиль, RESTful — реализация, следующая всем ограничениям REST
  • Что такое Uniform Interface? — Единообразие: любой ресурс доступен через одинаковый набор операций (GET/PUT/POST/DELETE)
  • Какой уровень зрелости Richardson считается стандартом? — Level 2: HTTP методы и статус-коды
  • Когда REST — плохой выбор? — Real-time streaming, внутренние микросервисы с жёсткими latency, графовые запросы

Красные флаги (НЕ говорить):

  • «REST — это протокол» — это архитектурный стиль, не протокол
  • «Любой HTTP API — это REST» — REST требует соблюдения всех 6 ограничений, включая HATEOAS
  • «GET можно использовать для удаления» — GET должен быть безопасным (Safe), не менять состояние
  • «HATEOAS обязателен в каждом проекте» — для внутренних микросервисов и mobile приложений HATEOAS избыточен

Связанные темы:

  • [[Что означает Stateless в контексте REST]]
  • [[Что такое RESTful API дизайн]]
  • [[Что такое HATEOAS]]
  • [[Какие HTTP статус коды вы знаете]]
  • [[Что такое Accept header]]