API простими словами: як сервіси розмовляють між собою

API простими словами: як сервіси розмовляють між собою

  • 16 липня
  • читати 7 хв
Галина Чорнодуб
Галина Чорнодуб QA Lead у Flawless, Викладач Комп'ютерної школи Hillel.

Якщо ви стикалися з терміном API і не були впевнені у його значенні, ця стаття допоможе розібратися за допомогою простих прикладів без зайвої технічної мови.

ЩО ТАКЕ API НАСПРАВДІ

API (Application Programming Interface, або інтерфейс програмування застосунків) — набір правил, що дозволяє одній програмі звертатися до іншої та отримувати відповідь.

Уявіть ресторан: ви — клієнт (програма А), кухня — інший сервіс (програма Б). Ви робите замовлення офіціантові, який передає його на кухню. Кухня готує страву, а офіціант її приносить.

API виконує роль офіціанта: приймає запит, передає його потрібному сервісу та повертає результат.

НАВІЩО ЦЕ ПОТРІБНО

Наприклад, в інтернет-магазині одягу, коли ви оформлюєте замовлення та вводите дані картки, магазин передає платіж через API платіжній системі (наприклад, LiqPay), яка перевіряє картку та списує кошти. Так само, вартість і терміни доставки надходять через API служби доставки (наприклад, «Нової пошти»), яка має актуальні адреси відділень і тарифи.

Завдяки API сервіси можуть використовувати готові рішення для платежів, доставки чи авторизації, не розробляючи їх самостійно.

Ось ще кілька прикладів використання API у повсякденному житті.

  • Погодний віджет на телефоні щогодини звертається через API до метеорологічного сервісу для оновлення прогнозу.
  • Під час бронювання готелю через Booking.com сервіс одночасно отримує через API дані з десятків готельних систем, щоб відображати актуальні ціни й наявність номерів.

ЯК ВИГЛЯДАЄ РОЗМОВА СЕРВІСІВ

Взаємодія між сервісами через API відбувається за принципом запит — відповідь (request — response).

  1. Клієнт надсилає запит (request), вказуючи, яку інформацію потрібно отримати.
  2. Сервер обробляє запит і виконує необхідну дію, наприклад, шукає, зберігає або видаляє дані.
  3. Сервер повертає відповідь (response) — результат виконання із зазначенням статусу: успішно або з помилкою.

Один із найпоширеніших підходів до організації такої взаємодії — REST (Representational State Transfer). REST — це набір принципів для зручного проєктування API, а не окрема технологія чи протокол. Зазвичай REST реалізують через протокол HTTP, який також використовує браузер для завантаження сайтів. Такі API називають REST API.

З ЧОГО СКЛАДАЄТЬСЯ ЗАПИТ

Коли одна програма звертається до іншої через API, запит зазвичай містить такі елементи.

  • URL (адреса) —  куди саме звертаємося. Наприклад: https://api.shop.com/products/123
  • Метод (HTTP method) — це дія, яку потрібно виконати.
    • GET — отримати дані. Наприклад, відкрити сторінку товару та отримати його опис, ціну, фото.
    • POST — створити новий об'єкт. Наприклад, оформити замовлення або зареєструвати акаунт.
    • PUT/PATCH — оновити існуючі дані. Наприклад, змінити адресу доставки в уже створеному замовленні.
    • DELETE — видалити дані. Наприклад, прибрати товар із кошика.
  • Заголовки (headers) — додаткова службова інформація, наприклад, формат даних або токен авторизації.
  • Тіло запиту (body) — дані, які передаються, зазвичай для POST і PUT.

З ЧОГО СКЛАДАЄТЬСЯ ВІДПОВІДЬ

Сервер, отримавши запит, повертає відповідь. Наприклад, після натискання «Оформити замовлення» застосунок надсилає запит до сервера, і у відповідь сервер надсилає:

  • Статус-код — коротке резюме результату обробки запиту. Наприклад:
    • 200 OK — сервер успішно обробив запит і повернув дані (наприклад, ви запитали інформацію про товар й отримали її)
    • 201 Created — новий об'єкт успішно створено (наприклад, замовлення оформлено та збережено в базі даних)
    • 400 Bad Request — застосунок надіслав запит з помилкою, наприклад, забув вказати номер телефону, який є обов'язковим полем
    • 401 Unauthorized — ви намагаєтесь оформити замовлення, не увійшовши в акаунт
    • 404 Not Found — ви запитуєте товар за ID, якого вже немає в каталозі (наприклад, його видалили)
    • 500 Internal Server Error — щось зламалося на боці сервера, наприклад він не зміг з'єднатися з базою даних
  • Тіло відповіді (body) — дані у форматі JSON. Якщо замовлення створено успішно, тіло відповіді містить його номер, суму та статус.
{

 "orderId": 4521,

 "status": "confirmed",

 "totalPrice": 1250

}

Тестувальник перевіряє, чи відповідає статус-код конкретній ситуації та чи містить тіло відповіді очікувані й коректні дані.

Приклад «розмови»

Уявімо застосунок погоди, який запитує дані про погоду в Києві.

Запит:

GET https://api.weather.com/current?city=Kyiv

Відповідь:

{

 "city": "Kyiv",

 "temperature": 24,

 "condition": "Sunny"

}

Застосунок надіслав запит: «дай погоду для Києва» й отримав структуровані дані, які потім відображаються користувачу у зрозумілому інтерфейсі.

А ДО ЧОГО ТУТ QA

Тестувальнику не обов'язково створювати API, але для якісного тестування сучасних застосунків важливо розуміти принципи його роботи. Ось де ці знання знадобляться на практиці:

Читання документації. API зазвичай описують у форматі Swagger/OpenAPI, де вказані доступні запити, обов'язкові параметри й очікувана відповідь. Вміння працювати з такою документацією є базовою навичкою. Замість натискання кнопок у застосунку можна одразу надіслати запит через Postman. Це швидше і дозволяє перевірити логіку, яку користувач не бачить.

Postman — зручна безкоштовна програма для створення та надсилання запитів до API. Щоб зробити простий запит у Postman, потрібно скопіювати URL з документації, обрати потрібний метод (наприклад, GET), натиснути «Send» і переглянути результат у відповідному вікні. Це дозволяє тестувати API навіть без розробників і швидко виявляти проблеми.

Перевірка коректності відповідей. Наприклад, чи повертає сервер 404, коли товару немає, або чи виникає помилка 500, якщо поле залишено порожнім. Такі перевірки часто дозволяють виявити помилки, які не видно в інтерфейсі.

Типові кроки для тестування API:

  • Ознайомитися з документацією API, щоб зрозуміти можливі запити і очікувані відповіді.
  • Підготувати тестові запити до API (наприклад, у Postman): обрати правильний URL, метод і параметри.
  • Надіслати запити й перевірити відповіді: статус-коди, тіло відповіді, вміст полів.
  • Порівняти отримані дані з документацією, щоб впевнитись у їхній коректності.
  • Звернути увагу на нестандартні або помилкові ситуації: некоректні дані, відсутність обов'язкових полів, неправильні параметри.

Локалізація проблеми. Розуміння API допомагає швидко визначити, чи проблема у відображенні даних на фронтенді чи у відповідях сервера.

Тестування через API дозволяє знаходити помилки раніше та швидше, ніж через інтерфейс, оскільки перевіряється логіка системи, а не лише її зовнішній вигляд.

Рекомендуємо курси по темі

Головне, що варто запам'ятати

  • API — це посередник, який дозволяє програмам обмінюватися даними за чіткими правилами
  • Спілкування відбувається за принципом запит — відповідь
  • У запиті вказується адреса, метод, заголовки та (за потреби) дані
  • У відповіді є статус-код і, зазвичай, дані у форматі JSON
  • Розуміння API — обов'язковий навик сучасного QA-фахівця
  • Щоб запобігти помилкам на ранніх етапах, рекомендується тестувати API окремо від інтерфейсу, звіряти відповіді з документацією і перевіряти граничні й негативні сценарії: некоректні дані, відсутність авторизації, порожні поля. Наприклад, можна надіслати запит із відсутнім обов'язковим полем (наприклад, без номера телефону) та впевнитися, що сервер повертає помилку 400 Bad Request. Або спробувати оформити замовлення без токена авторизації і перевірити, що відповідь містить статус-код 401 Unauthorized. Це дозволяє виявити проблему до того, як вона потрапить у продакшн.

Рекомендуємо публікації по темі