Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Що таке REST?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**REST (Representational State Transfer)** - це **архітектурний стиль** для побудови мережевих застосунків і API, який описує, як клієнт і сервер мають взаємодіяти по HTTP. Простіше кажучи, це набір принципів, за якими зручно і зрозуміло робити API. **Ключове:** REST - це не протокол і не технологія, а правила і підходи, що зазвичай реалізуються поверх HTTP.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**REST (Representational State Transfer)** - це **архітектурний стиль** для побудови мережевих застосунків і API, який описує, **як клієнт і сервер мають взаємодіяти по HTTP**. Простіше кажучи: **REST - це набір принципів, за якими зручно і зрозуміло робити API**. --- ## Що важливо зрозуміти одразу REST - це **не протокол** і **не технологія**. Це **правила і підходи**, які зазвичай реалізуються поверх **HTTP**. --- ## Основна ідея REST REST будується навколо **ресурсів**. - ресурс - це об'єкт або сутність (користувач, замовлення, товар) - у ресурсу є **URL** - над ресурсом виконуються дії через **HTTP-методи** Приклад: - `/users/1` - користувач - GET - отримати - POST - створити - PUT / PATCH - змінити - DELETE - видалити --- ## Основні принципи REST (простою мовою) ### 1. Клієнт-сервер - клієнт і сервер розділені - клієнт відповідає за інтерфейс - сервер - за дані і логіку Їх можна розвивати незалежно. --- ### 2. Stateless (без стану) - сервер **не зберігає стан клієнта** - кожен запит містить усю потрібну інформацію Ми вже це обговорювали, це ключовий принцип REST. --- ### 3. Ресурси і URL - усе - ресурси - кожен ресурс має **унікальний URL** - URL описує **що**, а не **як** `/getUser?id=1` погано `/users/1` добре --- ### 4. Використання HTTP-методів за призначенням - GET - отримати - POST - створити - PUT - замінити - PATCH - змінити - DELETE - видалити Це робить API передбачуваним. --- ### 5. Використання HTTP-статусів - 200 - успіх - 404 - не знайдено - 401 - немає доступу - 500 - помилка сервера Клієнт **розуміє результат без аналізу тексту**. --- ### 6. Єдиний інтерфейс - однакові правила для всіх ресурсів - однакові формати відповідей (часто JSON) API простіше вивчати і використовувати. --- ## REST на практиці (приклад) Запит: ``` GET /users/1 ``` Відповідь: ```json { "id": 1, "name": "Alice" } ``` Зрозуміло навіть без документації: - що робимо - з чим - який результат --- ## REST ≠ REST API (часта помилка) - **REST** - архітектурний стиль - **REST API** - API, побудований за принципами REST Більшість "REST API" на практиці - **REST-like**, але цього достатньо. --- ## Приклад з життя REST - це як магазин із правилами: - адреса - де перебуває товар - метод - що ти хочеш зробити - відповідь - результат (успіх або помилка) Усі знають правила, плутанини немає. --- ## Коротка відповідь для співбесіди Запам'ятай формулювання: > **REST - це архітектурний стиль взаємодії клієнт-серверних застосунків, заснований на роботі з ресурсами через HTTP, використанні стандартних методів, stateless-підході і HTTP-кодах відповіді.**Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.