Запуск проєкту та тестування API
Запускаємо Spring Boot застосунок і перевіряємо роботу ендпоінтів через Postman/браузер — без фронтенду, тільки HTTP.
Запуск і тестування (15.1.png)
Рис. 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) без фронтенду.

← Назад Далі →