VVERSUSSDigital guide
English
Головна / Software
Software·Oct 13, 2026·Редакція Versuss

Що таке REST API: методи, коди статусу та приклади

REST API дає кожному фрагменту даних власну адресу й використовує методи HTTP на кшталт GET і POST. Запити, коди статусу, принципи та порівняння з GraphQL.

Ілюстрація до статті: Що таке REST API: методи, коди статусу та приклади

REST — найпоширеніший стиль побудови веб-API. Коли мобільний застосунок завантажує повідомлення, сайт показує актуальні ціни чи система однієї компанії передає замовлення іншій, дані дуже ймовірно передає REST API. У цій статті — що означає «REST», як побудований REST-запит, що роблять HTTP-методи й коди статусу і чим REST відрізняється від альтернатив на кшталт GraphQL.

Ідея в одному абзаці

REST API подає дані як ресурси, кожен зі своєю вебадресою (URL), і дозволяє працювати з ними стандартними методами HTTP — того самого протоколу, яким браузер завантажує сторінки. Користувач, замовлення чи фото мають свій URL; прочитати — це GET, створити — POST і так далі. Відповіді зазвичай у форматі JSON — легкому текстовому форматі, зрозумілому і людям, і програмам. Якщо API для вас нова тема, почніть зі статті що робить API.

REST — це Representational State Transfer, набір принципів, описаний Роєм Філдінгом у 2000 році. У повсякденній мові «REST API» означає HTTP API, організоване навколо ресурсів і методів.

З чого складається REST-запит

  • Метод — що ви хочете зробити, наприклад GET чи POST.
  • URL — який ресурс, наприклад https://api.example.com/v1/orders/1042.
  • Заголовки — додаткова інформація: облікові дані (Authorization) і формат даних (Content-Type: application/json).
  • Тіло — дані, що надсилаються під час створення чи зміни.

Повний обмін виглядає так:

GET /v1/orders/1042 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 1042, "status": "shipped", "total": 49.90, "currency": "EUR"}

HTTP-методи — дієслова REST

Метод Призначення Приклад
GET Прочитати ресурс чи список GET /orders?status=open
POST Створити новий ресурс POST /orders із замовленням у тілі
PUT Повністю замінити ресурс PUT /orders/1042
PATCH Змінити окремі поля PATCH /orders/1042 з {"status":"cancelled"}
DELETE Видалити ресурс DELETE /orders/1042

GET ніколи не повинен змінювати дані — його можна безпечно повторювати, кешувати й завантажувати наперед. PUT і DELETE теж розраховані на повторення: двічі виконана дія дає той самий результат. POST — ні: те саме замовлення, надіслане двічі, може створити два. Тому добрі API для платежів підтримують ключ ідемпотентності.

Коди статусу — як відповідає сервер

  • 2xx успіх: 200 OK, 201 Created, 204 No Content.
  • 3xx перенаправлення: ресурс деінде, або 304 Not Modified, коли кешована копія ще дійсна.
  • 4xx помилки клієнта: 400 — некоректні дані, 401 — немає або неправильні облікові дані, 403 — бракує прав, 404 — не знайдено, 429 — перевищено ліміт запитів.
  • 5xx помилки сервера: 500, 502, 503 — проблема на боці провайдера, повторіть пізніше.

Код статусу варто читати першим — це економить багато часу. 401 — проблема з ключем, 400 — з тим, що ви надіслали, а 503 — зовсім не ваша провина.

Принципи REST, що важливі на практиці

  • Запити без стану. Кожен запит містить усе потрібне серверу, зокрема облікові дані. Сервер не пам’ятає попередніх викликів, тому REST API легко масштабувати на багато машин.
  • Ресурси, а не дії, в адресах. Краще POST /orders, ніж /createOrder: іменники в шляху, дієслова в методі.
  • Кешовані відповіді. Оскільки GET безпечний, відповіді можуть мати ті самі заголовки кешування, що й сторінки, — див. як працює кеш браузера.
  • Однаковий інтерфейс. Знаючи одне добре спроєктоване REST API, наступне сприймаєте легко: ті самі методи, коди й JSON.

REST, GraphQL та інші підходи

GraphQL має одну точку доступу, куди клієнт надсилає запит із переліком потрібних полів. Це дозволяє не завантажувати зайве й отримувати пов’язані дані за один запит, що зручно для складних інтерфейсів. Ціна — складніше кешування й серверна логіка.

gRPC використовує компактні двійкові повідомлення й популярний для швидкого обміну між внутрішніми сервісами. Вебхуки змінюють напрям: провайдер сам викликає вашу адресу, коли щось стається, замість того щоб ви постійно питали.

Для публічних API REST лишається стандартом, бо працює з будь-якою мовою програмування, будь-яким HTTP-інструментом і наявною вебінфраструктурою.

Як спробувати REST API самому

  1. Оберіть безкоштовне публічне API без ключа — погода, курси валют чи тестове API.
  2. Відкрийте його адресу в браузері: GET-запит одразу покаже JSON.
  3. Скористайтеся командним рядком, наприклад curl -i https://api.example.com/v1/items, щоб побачити код статусу й заголовки.
  4. Для API з обліковими даними додайте заголовок із документації. Варіанти описано в статті API-ключ і OAuth.

Часті запитання

Чи кожне HTTP API є REST?

Не зовсім. Багато API, що називають себе REST, порушують правила, наприклад використовують лише POST. У побуті термін охоплює будь-яке HTTP API на ресурсах, що повертає JSON.

Чи обов’язково REST використовує JSON?

Ні, REST не залежить від формату: підходять XML та інші. JSON став стандартом, бо він компактний і рідний для JavaScript.

Що таке ендпоінт?

Ендпоінт — конкретна пара адреси й методу, яку підтримує API, наприклад GET /v1/orders/{id}. Документація API зазвичай і є списком ендпоінтів.

Що означає версіонування API?

Провайдери додають версію в адресу (/v1/) чи заголовок, щоб змінювати API, не ламаючи наявних клієнтів. Коли з’являється /v2/, /v1/ зазвичай ще якийсь час працює.

Коротко: REST API дає кожному фрагменту даних власну адресу й дозволяє читати та змінювати його стандартними методами HTTP, отримуючи JSON і зрозумілі коди статусу. Запити без стану й кешування роблять REST простим у використанні та масштабуванні — тому це найпоширеніший спосіб, у який системи спілкуються в мережі.

Схожі статті