Java Interview Questions

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

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

Що таке RESTful API дизайн?

4. Повертайте правильні статус-коди:

Ukrainian REST HTTP Вихідний Markdown
Мовні версії: English Russian Ukrainian

Junior Level

RESTful дизайн — це правила створення API, які слідують принципам REST.

Основні правила:

  1. Використовуйте іменники для ресурсів:
    • ✅ GET /users — отримати користувачів
    • ❌ GET /getUsers — дієслова не потрібні
  2. Використовуйте правильні HTTP методи:
    • GET — читання
    • POST — створення
    • PUT — повне оновлення
    • PATCH — часткове оновлення
    • DELETE — видалення
  3. Використовуйте множину:
    • Рекомендується множина — це найпоширеніша конвенція.
    • Але однина теж допустима, якщо команда домовилась.
    • ✅ /users, /orders, /products
    • ❌ /user, /order, /product
  4. Повертайте правильні статус-коди:
    • 200 — успіх
    • 201 — створено
    • 400 — помилка клієнта
    • 404 — не знайдено
    • 500 — помилка сервера

Приклад хорошого RESTful API:

GET    /users          — список користувачів
GET    /users/1        — користувач з ID 1
POST   /users          — створити користувача
PUT    /users/1        — оновити користувача цілком
PATCH  /users/1        — частково оновити користувача
DELETE /users/1        — видалити користувача

Middle Level

Richardson Maturity Model

  • Level 0 (The Swamp of POX): HTTP як транспорт (RPC через HTTP)
  • Level 1 (Resources): Використання ресурсів (окремі URI)
  • Level 2 (HTTP Verbs & Statuses): HTTP методи та статус-коди. Це “золотий стандарт” індустрії
  • Level 3 (HATEOAS): Гіпермедіа. Найдорожчий рівень — оверхед на побудову графу посилань і збільшення JSON на 30-50%

Design-First vs Code-First

  1. Design-First (OpenAPI/Swagger YAML): Спочатку контракт, потім генерується код
    • Плюс: Паралельна розробка фронтенду і бекенду. Гарантія відповідності документації
    • Мінус: Складність підтримки YAML при частих змінах
  2. Code-First (SpringDoc/Swagger Annotations): Спочатку код, документація генерується з анотацій
    • Плюс: Швидка ітерація
    • Мінус: Документація часто “відстає” від коду

Продуктивність

  • Idempotency у дизайні: Проектуйте API так, щоб PUT і DELETE були безпечними для повторів. Це дозволяє використовувати агресивні політики повторів на рівні Service Mesh (Istio)
  • Payload Optimization: У Highload-системах замість JSON використовують REST-over-Protobuf або MessagePack
  • Negative Caching: Negative Caching — кешування помилкових відповідей. Якщо зловмисник сканує API неіснуючими запитами, CDN віддасть кешований 404 замість навантаження на бекенд. 1 секунда — компроміс: захист від brute-force без ризику, що легітимний клієнт довго не побачить ресурс, що з’явився. Налаштуйте CDN так, щоб відповіді 404 і 403 кешувалися на короткий час (1 сек).

N+1 Problem у REST

На відміну від GraphQL, REST страждає від надмірних запитів.

  • Рішення: Параметр embed або include (/orders?include=items)

HTTP Method Tunneling

Якщо клієнт не підтримує PATCH, використовуйте POST із заголовком X-HTTP-Method-Override: PATCH.

Senior Level

Коли RESTful дизайн надлишковий

  1. Внутрішні мікросервіси — краще gRPC/Thrift
  2. Real-time streaming — WebSocket/gRPC
  3. Simple RPC-виклики без CRUD-семантики

DispatcherServlet і HandlerMapping

У Spring MVC за реалізацію RESTful дизайну відповідає DispatcherServlet, який використовує HandlerMapping для зіставлення комбінації HTTP Method + URI з конкретним методом контролера.

Рівні зрілості та їх ціна

  • Level 2: Тут важливо не тільки використовувати POST, але й повертати 201 Created із заголовком Location
  • Level 3: Основна складність — оверхед на побудову графу посилань і збільшення розміру JSON

Діагностика і Моніторинг

  • Correlation ID: Рекомендується включати X-Request-ID (або X-Correlation-ID) у кожну відповідь. Цей ID передається через всі мікросервіси в ланцюжку викликів, дозволяючи зібрати всі логи одного запиту в ELK.
  • Problem Details (RFC 9457): Spring Boot 3+ підтримує через ProblemDetail. Робить помилки машиночитабельними
  • Latency Monitoring: Відстежуйте гістограми затримок (P99) не за ендпоінтами, а в розрізі методів (GET vs POST), оскільки їх профіль навантаження принципово різний

Edge Cases

  • Trailing Slash: /users/ і /users — два різних ресурси. Налаштуйте StrictTrailingSlashPatternMatch у Spring
  • API Discovery: Добре спроектований API дозволяє викликати OPTIONS /users і отримати список доступних методів

🎯 Шпаргалка для співбесіди

Обов’язково знати:

  • RESTful дизайн = іменники в URI + правильні HTTP методи + множина + статус-коди
  • Richardson Maturity Model: Level 2 (HTTP Verbs + Status Codes) — золотий стандарт індустрії
  • Design-First (OpenAPI/Swagger) vs Code-First (SpringDoc) — Design-First гарантує паралельну розробку
  • HATEOAS (Level 3) — найдорожчий рівень, оверхед 30-50% на JSON, не потрібен для внутрішніх мікросервісів
  • N+1 Problem у REST вирішується через embed/include параметри (/orders?include=items)
  • Negative Caching — кешування 404/403 відповідей для захисту від brute-force сканування
  • Для внутрішніх мікросервісів краще gRPC, для real-time — WebSockets

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

  • Чому множина в URI? — /users представляє колекцію, /users/1 — елемент колекції
  • Коли Design-First кращий за Code-First? — Коли фронтенд і бекенд розробляються паралельно
  • Що таке API Discovery? — Виклик OPTIONS /resource повертає список доступних методів
  • Чому HATEOAS рідко використовується? — Оверхед на генерацію посилань, збільшення JSON на 30-50%, не потрібен при одній команді

Червоні прапорці (НЕ говорити):

  • «Дієслова в URL — це нормально для REST» — URI має бути іменником, дія = HTTP метод
  • «HATEOAS обов’язковий у кожному проекті» — для внутрішніх API і мобільних додатків надлишковий
  • «REST підходить для всього» — для streaming і RPC краще gRPC/WebSockets
  • «Code-First завжди кращий» — документація часто відстає від коду, Design-First дає контракт

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

  • [[Що таке REST]]
  • [[Як правильно іменувати REST endpoints]]
  • [[Чи варто використовувати дієслова в URL]]
  • [[Що таке HATEOAS]]
  • [[Які HTTP статус коди ви знаєте]]