Бази даних, API та взаємодія вебсистем: як сайти зберігають інформацію й обмінюються нею.

1. Чому вебсайту потрібні бази даних та API?

Уявімо звичайний інтернет-магазин.

Користувач відкриває сайт і бачить каталог товарів. Він може:

• переглядати товари;

• шукати потрібну модель;

• додавати товари в кошик;

• оформлювати замовлення;

• створювати обліковий запис;

• переглядати історію покупок.

HTML створює структуру сторінки, CSS відповідає за її вигляд, а JavaScript додає інтерактивність. Вебсервер приймає запити та передає користувачеві потрібні ресурси.

Якщо записати всю інформацію безпосередньо в HTML-файл, сайт матиме серйозні обмеження.

Якщо користувач оформить замовлення, потрібно буде десь зберегти його дані.

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

Для цього вебсистеми використовують дві важливі складові:

1. Бази даних — для зберігання, пошуку, зміни та організації інформації.

2. API — для взаємодії між різними частинами програмного забезпечення.

Саме вони допомагають перетворити набір вебсторінок на повноцінну систему.

2. Frontend і Backend: дві сторони вебзастосунку

Під час вивчення попередніх тем ми вже познайомилися з HTML, CSS, JavaScript і вебсервером. Тепер об'єднаємо ці поняття в одну загальну картину.

У веброзробці часто використовують два терміни: frontend і backend.

Frontend — клієнтська частина

Вона працює переважно в браузері та відповідає за:

• відображення сторінок;

• кнопки, форми та меню;

• анімації й інтерактивність;

• відображення отриманих із сервера даних;

• надсилання запитів до backend.

Основні технології frontend:

• HTML — структура;

• CSS — оформлення;

• JavaScript — логіка та інтерактивність.

Наприклад, коли ти натискаєш кнопку «Показати товари», JavaScript може надіслати запит до сервера, отримати список товарів і відобразити його на сторінці.

Backend — серверна частина

Вона відповідає за логіку, яку не варто або неможливо повністю виконувати в браузері:

• обробку запитів;

• перевірку отриманих даних;

• виконання бізнес-логіки;

• взаємодію з базами даних;

• перевірку прав доступу;

• обмін інформацією з іншими сервісами;

• формування відповідей для frontend.

Backend може бути написаний різними мовами програмування:

• JavaScript або TypeScript — наприклад, Node.js;

• Python;

• PHP;

• Java;

• C#;

• Go;

• Ruby.

Важливо: Node.js — це середовище виконання JavaScript поза браузером. Завдяки йому JavaScript можна використовувати не лише для frontend, а й для створення серверної частини.

Як вони взаємодіють?

Уявімо, що користувач відкриває каталог товарів.

1. Браузер відображає сторінку — це робота frontend.

2. JavaScript надсилає запит до сервера.

3. Backend отримує запит і визначає, які дані потрібні.

4. Backend звертається до бази даних.

5. База даних повертає інформацію.

6. Backend формує відповідь.

7. Браузер отримує дані та відображає товари.

Frontend і backend можуть бути написані різними мовами, працювати на різних серверах і навіть розроблятися різними командами.

Їх об'єднує узгоджений спосіб обміну інформацією.

Тут ми й підходимо до поняття API.

3. Що таке база даних?

База даних відрізняється від звичайного текстового файла тим, що спеціально призначена для систематизованої роботи з інформацією.

Наприклад, у базі даних інтернет-магазину можуть зберігатися:

• товари;

• категорії;

• користувачі;

• замовлення;

• оплати;

• відгуки;

• адреси доставки.

Коли користувач відкриває сторінку товару, сервер може отримати його назву, ціну, опис і фотографії з бази даних.

Коли користувач оформлює замовлення, сервер записує відповідну інформацію в базу.

3.1. СУБД — програма для роботи з базою даних

Необхідно розрізняти два поняття:

• База даних — організована інформація.

• СУБД (Database Management System, DBMS) — програмне забезпечення, яке дає змогу створювати бази даних, керувати ними та виконувати операції з інформацією.

СУБД забезпечує зберігання даних, виконання запитів, керування доступом та інші функції.

Популярні приклади:

Для початкового знайомства з базами даних зручно використовувати PostgreSQL або SQLite.

4. Реляційні бази даних: таблиці, рядки та стовпці

Уявімо, що ми створюємо просту базу даних інтернет-магазину.

У ній є таблиця товарів:

Розглянемо структуру.

Таблиця (Table) — місце, де зберігається певна категорія інформації. Наприклад, товари або користувачі.

Стовпець (Column) — характеристика, яка зберігається для кожного запису. Наприклад, назва, ціна або кількість товару.

Рядок (Row) — окремий запис у таблиці. Наприклад, конкретна модель навушників.

Поле (Field) — окреме значення в записі, наприклад ціна товару.  Елемент структури запису, який містить певну характеристику. 

Наприклад, поле price містить ціну конкретного товару. У контексті таблиці поле часто відповідає стовпцю або окремому значенню в ньому — залежно від способу вживання терміна. 

4.1. Первинний ключ — Primary Key

У таблиці кожен товар повинен мати спосіб однозначної ідентифікації.

Для цього використовують первинний ключ.

Primary Key (PK) — стовпець або набір стовпців, які однозначно визначають кожен запис у таблиці.

У нашому прикладі таким ключем є id.

Наприклад:

• товар із id = 1 — навушники;

• товар із id = 2 — клавіатура;

• товар із id = 3 — миша.

Завдяки цьому система може звернутися до конкретного товару, навіть якщо його назва зміниться.

4.2. Зовнішній ключ — Foreign Key

Тепер створимо таблицю замовлень.

Зверни увагу на стовпець product_id.

Він містить ідентифікатори товарів із попередньої таблиці.

Тобто:

• замовлення 101 стосується товару з id = 1;

• замовлення 102 — товару з id = 3;

• замовлення 103 — товару з id = 2.

Для спрощення в цьому прикладі кожне замовлення містить лише один товар.

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

orders

- id

- customer_id

- order_date


order_items

- id

- order_id

- product_id

- quantity

Тоді одне замовлення може мати декілька записів у order_items. 

Foreign Key (FK) — зовнішній ключ, який посилається на ключ іншої таблиці та допомагає встановлювати зв'язки між даними.

Зв'язок потрібно оголосити в структурі бази даних за допомогою обмеження FOREIGN KEY. Тоді СУБД зможе контролювати відповідність значень і підтримувати цілісність даних. 

У нашому прикладі product_id посилається на id у таблиці товарів.

Це дозволяє зберігати інформацію про товар в одному місці, а в замовленнях використовувати посилання на нього.

4.3. Навіщо пов'язувати таблиці?

Якби кожне замовлення містило повну копію всієї інформації про товар, виникали б проблеми:

• однакова інформація повторювалася б багато разів;

• зміна назви товару вимагала б оновлення багатьох записів;

• помилки могли б призводити до суперечностей.

Зв'язки між таблицями допомагають уникати зайвого дублювання та підтримувати цілісність даних.

• Один до одного (One-to-One)

Один запис пов'язаний з одним записом іншої таблиці.

• Один до багатьох (One-to-Many)

Один запис може бути пов'язаний із багатьма записами іншої таблиці.

• Багато до багатьох (Many-to-Many)

Багато записів однієї таблиці можуть бути пов'язані з багатьма записами іншої.

Для реалізації такого зв'язку зазвичай створюють проміжну таблицю.

5. SQL — мова для роботи з реляційними базами даних

SQL (Structured Query Language) — мова структурованих запитів, за допомогою якої можна взаємодіяти з реляційними базами даних.

SQL дає змогу:

• створювати таблиці;

• додавати інформацію;

• отримувати потрібні записи;

• змінювати дані;

• видаляти дані;

• встановлювати зв'язки між таблицями.

Розглянемо основні команди на прикладі таблиці products.

5.1. SELECT — отримання даних

Команда SELECT використовується для отримання інформації з таблиці.

SELECT * FROM products;

Цей запит повертає всі стовпці та записи таблиці products.

Якщо потрібні лише назви й ціни:

SELECT name, price

FROM products;

Можна також встановлювати умови пошуку за допомогою WHERE.

SELECT *

FROM products

WHERE price > 1000;

Цей запит поверне товари, ціна яких перевищує 1000.

5.2. INSERT — додавання даних

Команда INSERT додає новий запис до таблиці.

INSERT INTO products (name, price, quantity)

VALUES ('Монітор', 6500, 5);

Ми додаємо новий товар із назвою «Монітор», ціною 6500 та кількістю 5.

5.3. UPDATE — зміна даних

Команда UPDATE змінює інформацію в наявних записах.

UPDATE products

SET price = 7000

WHERE id = 4;

Цей запит змінює ціну товару з ідентифікатором 4.

Якщо забрати умову:

UPDATE products

SET price = 7000;

ціна зміниться для всіх товарів у таблиці.

5.4. DELETE — видалення даних

Команда DELETE видаляє записи з таблиці.

DELETE FROM products

WHERE id = 4;

Цей запит видалить товар з ідентифікатором 4.

DELETE FROM products;

Тому під час роботи з UPDATE та DELETE потрібно уважно перевіряти умови.

5.5. JOIN — об'єднання інформації з таблиць

Ми вже знаємо, що таблиці можуть бути пов'язані між собою.

Для цього використовують JOIN.

Наприклад, потрібно отримати назву товару та ім'я покупця для кожного замовлення.

SELECT

    orders.id,

    orders.customer_name,

    products.name,

    orders.quantity

FROM orders

JOIN products

    ON orders.product_id = products.id;

База даних зіставить product_id із id товару та поверне об'єднану інформацію.

Результат умовно матиме такий вигляд:

Це лише початкове знайомство з SQL. У реальних проєктах використовують набагато більше команд, умов, функцій і механізмів.

6. NoSQL: альтернативний спосіб зберігання інформації

Реляційні бази даних не є єдиним способом організації даних.

NoSQL — загальна назва для різних підходів до зберігання даних, які не обов'язково використовують традиційну реляційну модель із таблицями та зв'язками.

Одним із відомих прикладів є документоорієнтована база даних MongoDB.

6.1. Як працює документоорієнтована база даних?

Замість таблиць із фіксованими стовпцями така база може зберігати документи.

Наприклад, інформація про товар може виглядати так:

{

  "id": 1,

  "name": "Навушники",

  "price": 1500,

  "quantity": 12,

  "specifications": {

    "color": "black",

    "wireless": true

  }

}

Це JSON-подібне представлення даних.

Інший товар може мати додаткові характеристики:

{

  "id": 2,

  "name": "Клавіатура",

  "price": 2300,

  "quantity": 8,

  "specifications": {

    "layout": "Ukrainian",

    "backlight": true,

    "connection": "USB"

  }

}

Структура документів може бути гнучкішою: різні документи в одній колекції не обов'язково повинні мати однакові поля.

У MongoDB документи організовують у колекції. Колекцію можна приблизно порівняти з таблицею реляційної бази, а документ — із записом у ній. Проте принципи організації та роботи відрізняються.

6.2. Чим реляційні та документоорієнтовані NoSQL-бази даних відрізняються? 

Реляційні та NoSQL-бази даних відрізняються насамперед способом організації та зберігання інформації.

NoSQL — це загальна назва для різних підходів до зберігання даних, які не обмежуються традиційною табличною моделлю. Наприклад, документоорієнтовані бази можуть зберігати інформацію у вигляді документів, схожих на JSON.

Це лише умовні приклади. Остаточний вибір СУБД залежить не від однієї характеристики даних, а від загальної моделі інформації, зв'язків між нею, типових запитів і вимог застосунку. 

Такі бази можуть мати гнучкішу структуру даних, хоча це не означає повної відсутності правил або обмежень.
Наприклад, MongoDB підтримує перевірку структури документів за допомогою механізмів валідації. 

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

Наприклад:

• для системи з великою кількістю взаємопов'язаних замовлень може добре підійти PostgreSQL;

• для каталогу з різноманітними характеристиками товарів може бути зручним документоорієнтований підхід;

• SQLite часто використовують у невеликих застосунках, локальних програмах і прототипах.

Важливо розуміти не назви технологій, а принципи, за якими вони працюють.

7. Що таке API?

API (Application Programming Interface) — програмний інтерфейс, який визначає, як одна програма або частина системи може взаємодіяти з іншою.

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

Відвідувач не заходить на кухню, щоб самостійно приготувати страву. Він передає замовлення офіціанту. Офіціант передає його кухні, а потім повертає готову страву.

У цій аналогії:

• відвідувач — програма, яка хоче отримати інформацію;

• офіціант — API;

• кухня — система, яка обробляє запит;

• страва — результат виконання запиту.

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

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

7.1. Де використовують API?

API є практично скрізь у сучасному програмному забезпеченні.

Наприклад:

Frontend звертається до API, щоб отримати каталог товарів, створити замовлення або перевірити його стан.

Застосунок надсилає запит до зовнішнього API та отримує прогноз погоди.

Вебсайт може використовувати API картографічного сервісу для відображення карти, маршрутів або місць.

Інтернет-магазин може взаємодіяти з платіжним сервісом через API, щоб ініціювати оплату та отримати інформацію про її результат.

Мобільний застосунок може використовувати той самий backend і API, що й вебверсія сервісу.

API дозволяє різним системам взаємодіяти, навіть якщо вони створені на різних мовах програмування та працюють на різних платформах.

Наприклад, фотографії та інші великі файли часто розміщують окремо — у файловому сховищі або спеціальному об'єктному сховищі. 

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

8. Endpoint, запит і відповідь API

У веброзробці часто використовують API, які працюють поверх HTTP або HTTPS.

Тут ми поєднуємо нову тему з матеріалом попередніх статей про HTTP і HTTPS.

8.1. Endpoint — точка доступу

Endpoint — це конкретна точка доступу до API, через яку можна виконати певну операцію. Зазвичай вона визначається шляхом (URL або його частиною) та HTTP-методом.

Наприклад:

• GET /api/products — отримати список товарів;

• POST /api/products — додати новий товар.

Endpoint — конкретна адреса API, до якої звертається клієнт для виконання певної операції.

Наприклад:

https://shop.example.com/api/products

Це умовна адреса, яка може використовуватися для отримання списку товарів.

Інший endpoint:

https://shop.example.com/api/products/15

Може повертати інформацію про товар з ідентифікатором 15.

Ще один:

https://shop.example.com/api/orders

Може використовуватися для роботи із замовленнями.

Усі ці адреси можуть належати одному API.

8.2. Request — запит

Коли клієнт звертається до API, він надсилає запит.

HTTP-запит може містити:

• метод HTTP;

• адресу ресурсу;

• заголовки;

• параметри;

• тіло запиту.

Наприклад, запит на отримання товарів:

GET /api/products HTTP/1.1

Host: shop.example.com

Accept: application/json

Тут:

• GET — метод запиту;

• /api/products — шлях до ресурсу;

• Host — назва сервера;

• Accept — формат даних, який клієнт очікує отримати.

8.3. Response — відповідь

Після обробки запиту сервер повертає відповідь.

Наприклад:

HTTP/1.1 200 OK

Content-Type: application/json

[

  {

    "id": 1,

    "name": "Навушники",

    "price": 1500

  },

  {

    "id": 2,

    "name": "Клавіатура",

    "price": 2300

  }

]

Сервер повідомляє, що запит успішний, і повертає дані у форматі JSON.

9. REST API та HTTP-методи

Один із найпоширеніших підходів до побудови веб API — REST.

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

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

У такому підході дані часто представляються як ресурси.

Наприклад:

• /products — товари;

• /users — користувачі;

• /orders — замовлення.

Для взаємодії з ресурсами використовують HTTP-методи.

9.1. Основні HTTP-методи

Розглянемо приклади.

GET /api/products

Сервер повертає список товарів.

POST /api/products

Content-Type: application/json

{

  "name": "Монітор",

  "price": 6500

}

Сервер отримує інформацію та, якщо запит коректний і дозволений, створює новий товар.

PUT /api/products/15

Content-Type: application/json

{

  "name": "Монітор",

  "price": 7000,

  "quantity": 5

}

У типовій REST-схемі PUT передає нове представлення ресурсу повністю.

PATCH /api/products/15

Content-Type: application/json

{

  "price": 7000

}

Тут ми змінюємо лише ціну товару.

DELETE /api/products/15

Сервер отримує команду видалити товар з ідентифікатором 15.

9.2. Статуси HTTP-відповідей

Після обробки запиту сервер повертає не лише дані, а й код стану HTTP.

Найважливіші групи:

• 1xx — інформаційні відповіді;

• 2xx — успішне виконання;

• 3xx — перенаправлення;

• 4xx — помилки на стороні клієнта;

• 5xx — помилки на стороні сервера.

Кілька кодів, які часто зустрічаються під час роботи з API:

Наприклад, якщо користувач не увійшов у систему, сервер може повернути 401. Якщо ж користувач увійшов, але не має прав для виконання певної операції, сервер може повернути 403. 

Інший приклад, якщо користувач звернувся до адреси товару, якого не існує, сервер може повернути 404 Not Found.

Ці коди допомагають клієнтській програмі зрозуміти результат запиту та правильно відреагувати на нього.

10. JSON — формат обміну даними

Ми вже неодноразово зустрічали JSON у прикладах API.

JSON (JavaScript Object Notation) — текстовий формат представлення та обміну структурованими даними.

Попри згадку JavaScript у назві, JSON не обмежується цією мовою. Його використовують різні мови програмування та платформи.

Наприклад:

{

  "id": 15,

  "name": "Монітор",

  "price": 6500,

  "available": true,

  "category": "Electronics"

}

Тут ми бачимо:

• id — числове значення;

• name — текст;

• price — число;

• available — логічне значення;

• category — текст.

JSON підтримує такі типи значень:

• рядки;

• числа;

• логічні значення true і false;

• null;

• об'єкти;

• масиви.

Наприклад, масив товарів:

{

  "products": [

    {

      "id": 1,

      "name": "Навушники",

      "price": 1500

    },

    {

      "id": 2,

      "name": "Клавіатура",

      "price": 2300

    }

  ]

}

У веброзробці JSON часто використовують для обміну даними між frontend і backend.

11. Як JavaScript отримує дані з API: Fetch API

Ми вже знаємо, що JavaScript відповідає за інтерактивність сторінки.

Але він може робити набагато більше, ніж реагувати на натискання кнопок.

Для цього в браузері існує Fetch API.

Функція fetch() дозволяє надсилати HTTP-запити та отримувати відповіді.

11.1. Отримання даних

Припустимо, що наш API має адресу:

https://shop.example.com/api/products

Потрібно отримати список товарів.

async function getProducts() {

    try {

        const response = await fetch(

            "https://shop.example.com/api/products"

        );




        if (!response.ok) {

            throw new Error("Помилка отримання товарів");

        }




        const products = await response.json();




        console.log(products);




    } catch (error) {

        console.error(error.message);

    }

}




getProducts();

Розберемо код.

Створює асинхронну функцію. Вона дозволяє використовувати await для очікування результату асинхронних операцій.

Надсилає запит за вказаною адресою.

Дозволяє дочекатися завершення операції, не блокуючи виконання всієї сторінки.

Містить об'єкт відповіді сервера. З нього можна отримати статус, заголовки та тіло відповіді.

Перевіряє, чи належить HTTP-статус до успішного діапазону 200–299.

Це важлива деталь: fetch() зазвичай не вважає HTTP-помилки на кшталт 404 або 500 помилкою самого мережевого запиту. Тому статус потрібно перевіряти окремо.

Читає тіло відповіді та перетворює JSON-текст на JavaScript-значення.

Дозволяє обробляти помилки, які можуть виникнути під час виконання операцій.

У результаті змінна products міститиме дані, отримані від API.

11.2. Надсилання даних на сервер

Тепер уявімо, що користувач хоче створити замовлення.

JavaScript може відправити дані за допомогою методу POST.

async function createOrder() {

    const order = {

        productId: 15,

        quantity: 2

    };




    try {

        const response = await fetch(

            "https://shop.example.com/api/orders",

            {

                method: "POST",




                headers: {

                    "Content-Type": "application/json"

                },




                body: JSON.stringify(order)

            }

        );




        if (!response.ok) {

            throw new Error("Не вдалося створити замовлення");

        }




        const result = await response.json();




        console.log("Замовлення створено:", result);




    } catch (error) {

        console.error(error.message);

    }

}

Тут з'явилися нові елементи.

Вказує, що ми використовуємо HTTP-метод POST.

Містить заголовки запиту.

Content-Type: application/json повідомляє серверу, що тіло запиту передається у форматі JSON.

Містить дані, які ми надсилаємо серверу.

Перетворює JavaScript-об'єкт на JSON-рядок.

Це потрібно, тому що тіло HTTP-запиту передається у вигляді даних, а не безпосередньо як JavaScript-об'єкт.

12. Що відбувається між API та базою даних?

Ми вже знаємо, як frontend надсилає запит до API.

Але що відбувається після того, як сервер отримав його?

Розглянемо створення замовлення.

Користувач натискає кнопку «Оформити замовлення».

Крок 1. Frontend формує запит

JavaScript збирає інформацію про товар, кількість та інші необхідні дані.

Крок 2. Запит надходить до backend

Сервер отримує HTTP-запит і визначає, який endpoint його оброблятиме.

Наприклад:

POST /api/orders

Крок 3. Backend перевіряє дані

Сервер перевіряє:

• чи передані необхідні поля;

• чи має товар правильний ідентифікатор;

• чи є товар у наявності;

• чи є кількість допустимою;

• чи має користувач право оформлювати замовлення.

Ці перевірки виконуються на сервері, навіть якщо frontend уже перевіряв введені дані.

Крок 4. Backend звертається до бази даних

Якщо запит пройшов перевірку, сервер може виконати SQL-запит.

Наприклад:

INSERT INTO orders (customer_name, product_id, quantity)

VALUES ('Олена', 15, 2);

У результаті в таблиці замовлень з'являється новий запис.

У реальному застосунку сервер також може перевірити наявність товару, розрахувати суму, зменшити залишок і виконати інші операції.

Крок 5. База даних повертає результат

СУБД повідомляє, чи вдалося виконати операцію, і за потреби повертає створений запис або його ідентифікатор.

Крок 6. Backend формує відповідь

Наприклад:

{

  "success": true,

  "orderId": 103,

  "message": "Замовлення створено"

}

Сервер може повернути статус 201 Created.

Крок 7. Frontend отримує результат

JavaScript отримує відповідь і може показати користувачеві повідомлення:

«Ваше замовлення успішно оформлено».

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

Узагальнення

Наприклад, під час оформлення замовлення система може одночасно створювати запис про замовлення та зменшувати кількість товару на складі.

Для цього використовують транзакції — механізм, який дозволяє об'єднати декілька операцій в одну логічну групу. Якщо всі операції виконалися успішно, зміни зберігаються. 

Якщо під час виконання виникла помилка, зміни можна скасувати, щоб база даних не залишилася в непослідовному стані.

13. Повна схема взаємодії вебсистеми

Тепер об'єднаємо всі вивчені компоненти.

У цій схемі кожна складова має власне призначення.

• Браузер — середовище, у якому користувач взаємодіє із сайтом.

• Frontend — відображає інтерфейс і надсилає запити.

• API — визначає спосіб взаємодії між програмними компонентами.

• Backend — обробляє запити та виконує серверну логіку.

• База даних — зберігає та повертає інформацію.

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

Тобто одна вебсистема може взаємодіяти з іншими системами через їхні API.

Саме так працює значна частина сучасних онлайн-сервісів.

14. Автентифікація та авторизація: коротке знайомство

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

Ці процеси пов'язані з двома поняттями.

Автентифікація (Authentication) — перевірка того, ким є користувач або система.

Наприклад, користувач вводить логін і пароль, а сервер перевіряє, чи відповідають вони обліковому запису.

Авторизація (Authorization) — визначення того, які дії дозволено виконувати користувачеві.

Наприклад:

• звичайний користувач може переглядати товари;

• покупець може створювати власні замовлення;

• адміністратор може додавати товари та змінювати ціни.

Це різні процеси.

Після входу система повинна певним чином підтримувати стан авторизованого користувача між запитами. Для цього використовують cookies, сесії та токени.

Оскільки це окрема важлива тема, детально розглянемо її в наступній статті.

15. Базова безпека під час роботи з базами даних та API

Бази даних можуть містити дуже важливу інформацію:

• персональні дані;

• адреси;

• паролі або їхні захищені похідні значення;

• історію замовлень;

• платіжну інформацію;

• внутрішні дані компанії.

Тому недостатньо просто навчитися зберігати та передавати інформацію. Потрібно розуміти основні ризики.

15.1. SQL Injection

SQL Injection (SQL-ін'єкція) — тип атаки, під час якої зловмисник намагається змінити структуру SQL-запиту за допомогою спеціально сформованих вхідних даних.

Уявімо, що програміст створив запит шляхом простого об'єднання тексту:

const query =

    "SELECT * FROM users WHERE name = '" + userInput + "'";

Якщо userInput містить спеціально сформований SQL-фрагмент, він може змінити логіку запиту.

Правильний підхід — використовувати параметризовані запити.

Наприклад, концептуально це може виглядати так:

SELECT *

FROM users

WHERE name = ?;

Значення передається окремим параметром через API конкретної СУБД або бібліотеки.

Таким чином база даних сприймає його як значення, а не як частину SQL-команди.

15.2. Чому не можна зберігати секретні ключі у frontend?

Припустимо, що вебзастосунок використовує API зовнішнього платіжного сервісу.

Якщо розмістити такий ключ безпосередньо в JavaScript-коді, який завантажується в браузер, користувач може переглянути його через інструменти розробника або отримати з файлів сайту.

Тому секретні ключі, паролі до баз даних та інші конфіденційні дані потрібно зберігати на сервері.

15.3. Перевірка вхідних даних

Не можна довіряти даним лише тому, що їх надіслав власний frontend.

Користувач може змінити запит, обійти клієнтські перевірки або надіслати дані безпосередньо до API.

Тому backend повинен перевіряти:

• типи даних;

• обов'язкові поля;

• допустимі значення;

• довжину тексту;

• числові межі;

• права користувача на виконання операції.

Клієнтська перевірка покращує зручність, але не замінює серверну.

16. Практичний приклад: як виглядає робота з API

Спробуємо об'єднати кілька понять у невеликому умовному прикладі.

Уявімо, що ми створюємо каталог товарів.

Наш API має endpoint:

GET /api/products

Сервер повертає:

[

  {

    "id": 1,

    "name": "Навушники",

    "price": 1500

  },

  {

    "id": 2,

    "name": "Клавіатура",

    "price": 2300

  }

]

Frontend повинен отримати ці дані та показати їх на сторінці.

Для цього можна використати такий JavaScript:

async function showProducts() {

    const response = await fetch("/api/products");




    if (!response.ok) {

        console.log("Не вдалося завантажити товари");

        return;

    }




    const products = await response.json();




    products.forEach(product => {

        console.log(

            product.name + " — " + product.price + " грн"

        );

    });

}




showProducts();

Якщо сервер повернув два товари, у консолі браузера ми побачимо:

• Навушники — 1500 грн

• Клавіатура — 2300 грн

Що тут відбулося?

1. JavaScript звернувся до /api/products.

2. Сервер отримав запит.

3. Backend отримав дані з бази.

4. Сервер повернув JSON.

5. JavaScript перетворив JSON на об'єкти.

6. Код перебрав отримані товари та вивів їх у консоль.

Цей приклад не потребує знання серверного програмування, але дозволяє побачити принцип взаємодії frontend та API.

17. Типові помилки під час знайомства з базами даних та API

База даних — це організована система зберігання та керування інформацією, яка може підтримувати пошук, зв'язки, обмеження та одночасну роботу багатьох користувачів.

База даних містить інформацію, а СУБД забезпечує програмні засоби для роботи з нею.

SQL — це мова запитів. PostgreSQL, MySQL та інші — системи керування базами даних.

API — це інтерфейс і правила взаємодії між програмами. Його можна реалізувати різними мовами та технологіями.

JSON — формат представлення та обміну даними. Він може використовуватися в API, файлах і деяких базах даних.

У типовій архітектурі frontend звертається до backend через API. Саме сервер виконує перевірки та взаємодіє з базою даних.

Клієнтські перевірки можна обійти. Важливі перевірки обов'язково повинні виконуватися на сервері.

404 Not Found означає, що потрібний ресурс не знайдено. Сам сервер при цьому може працювати цілком нормально.

18. Підсумок

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

Основні висновки:

• Frontend відповідає за користувацький інтерфейс і взаємодію з браузером.

• Backend виконує серверну логіку та обробляє запити.

• База даних зберігає інформацію, необхідну для роботи застосунку.

• СУБД забезпечує керування базою даних.

• Реляційні бази даних організовують інформацію в таблицях і використовують зв'язки між ними.

• SQL дозволяє створювати, отримувати, змінювати та видаляти дані.

• NoSQL — група альтернативних підходів до організації інформації.

• API визначає спосіб взаємодії між програмами.

• REST API часто використовує HTTP-методи для роботи з ресурсами.

• JSON є одним із найпоширеніших форматів обміну даними.

• Fetch API дозволяє JavaScript надсилати запити та отримувати відповіді.

• Backend взаємодіє з базою даних і повертає результат клієнту.

• Безпека потребує параметризованих запитів, перевірки даних і захисту секретів.

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

У наступній статті розглянемо ще один важливий механізм цієї системи — cookies, сесії та безпеку вебсайтів. З'ясуємо, як сайт запам'ятовує користувача між запитами, як працює авторизація та як захищають доступ до облікових записів.

19. Словник основних термінів