Java Interview Questions

Головна / Усі відповіді / REST HTTP

Питання 1 · Розділ 6

Що таке REST?

Це не протокол і не бібліотека, а набір рекомендацій (constraints). Сервіс можна назвати RESTful, лише якщо він дотримується всіх цих рекомендацій.

Ukrainian 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; до цього реактивні стеки були єдиним способом обробляти десятки тисяч з’єднань)
  • 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 дозволяють обробляти десятки тисяч з’єднань без реактивного стека

Часті уточнюючі запитання:

  • В чому різниця між 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 обов’язковий у кожному проекті» — для внутрішніх мікросервісів і мобільних додатків HATEOAS надлишковий

Пов’язані теми:

  • [[Що означає Stateless в контексті REST]]
  • [[Що таке RESTful API дизайн]]
  • [[Що таке HATEOAS]]
  • [[Які HTTP статус коди ви знаєте]]
  • [[Що таке Accept header]]