Запуск проєкту та тестування API
Запускаємо Spring Boot застосунок і перевіряємо роботу ендпоінтів через Postman/браузер — без фронтенду, тільки HTTP.
Рис. 15.1. Мінімальний план: запустити DemoApplication.java і протестувати GET /users та POST /users.

### 1) Запуск проєкту через DemoApplication.java

У Spring Boot “точка старту” — це клас з методом main():

@SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }

- В IntelliJ відкрий файл DemoApplication.java.
- Натисни зелений трикутник (Run) біля main().
- Дочекайся, поки застосунок підніметься (server started).

Що реально відбувається під капотом: Spring сканує пакети, знаходить @Controller/@Service/@Repository, створює обʼєкти, піднімає вбудований сервер (зазвичай Tomcat) і починає “слухати” порт.

### 2) Як зрозуміти, що сервер успішно запустився

У консолі IntelliJ ти маєш побачити щось типу:

Tomcat started on port(s): 8080 (http) Started DemoApplication in 2.345 seconds

- Ключове — порт 8080 і повідомлення “Started”.
- Після цього можна тестувати запити: http://localhost:8080

### 3) Найчастіші проблеми при запуску (і як пояснити студентам)

- Port already in use — порт 8080 вже зайнятий іншим застосунком.
- Помилка БД — неправильні налаштування datasource або драйвера.
- Не підтягуються залежності — Maven/Gradle ще не завантажив бібліотеки.
- ClassNotFound / NoSuchMethod — несумісні версії (наприклад Java не та).

Мінімальна порада: при будь-якій помилці не панікуємо. Читаємо перший “змістовний” рядок stacktrace (де написано причина), а не 200 рядків низу.

### 4) Тестування API без фронтенду: навіщо це потрібно

Ми ще не робимо UI/Frontend. Але нам треба перевірити, що “бекенд живий”:

- ендпоінт існує;
- контролер приймає запит;
- сервіс виконує логіку;
- репозиторій читає/пише в БД;
- у відповідь ми отримуємо JSON.

Тому Postman/браузер — це “викрутка” для бекенду: перевірити, що все працює ще до UI.

### 5) Запит №1: GET /users — отримати всіх користувачів

Виконай запит:

GET http://localhost:8080/users

- У браузері: просто відкрий URL — якщо ендпоінт повертає JSON, ти побачиш список.
- У Postman: обери метод GET → встав URL → Send.

Очікувана відповідь (якщо в БД ще порожньо):

[]

Питання студентам: “чому повертається [] ?” (бо в базі немає жодного запису — це нормальна поведінка)

### 6) Запит №2: POST /users — створити користувача

В Postman зроби так:

- Method: POST
- URL: http://localhost:8080/users
- Headers: Content-Type: application/json
- Body → raw → JSON

Тіло запиту:

{ "name": "John", "email": "john@example.com" }

Очікувана відповідь (зазвичай повертає створеного користувача):

{ "id": 1, "name": "John", "email": "john@example.com" }

Пояснення: id з’являється після save(). База даних генерує первинний ключ (IDENTITY), а JPA підставляє його назад у об’єкт.

### 7) Перевірка після POST: ще раз GET /users

Тепер повтори:

GET http://localhost:8080/users

І ти маєш побачити масив вже з 1 користувачем:

[ {"id": 1, "name": "John", "email": "john@example.com"} ]

### 8) Типові помилки при тестуванні (дуже корисно для практики)

- 404 Not Found — неправильний URL або контролер не піднявся.
- 405 Method Not Allowed — ти шлеш GET туди, де очікується POST (або навпаки).
- 415 Unsupported Media Type — не вказаний Content-Type: application/json.
- 400 Bad Request — JSON кривий або поля не відповідають класу.
- 500 Internal Server Error — помилка в коді/БД (читай лог у консолі).

Якщо бачиш 500 — це не “все пропало”. Це означає: “бекенд впав, бо в коді помилка”. Відкриваємо консоль, шукаємо рядок з причиною.

Підсумок: ми запустили Spring Boot застосунок і підтвердили, що API працює: можемо читати користувачів (GET) і створювати (POST) без фронтенду.