Controller: точка входу в REST API
Controller приймає HTTP-запити, викликає Service і повертає відповідь клієнту. Він не має “думати” — він має правильно “перекинути” запит у потрібну логіку.
Рис. 6. Клас UserController з REST-ендпоінтами: GET /users та POST /users.

### 1) Що таке Controller і навіщо він потрібен

Controller — це клас, який “слухає” HTTP-запити від клієнта (браузер, Postman, мобільний застосунок) і вирішує: який метод треба виконати.

- Controller працює з HTTP: URL, методи (GET/POST), статуси, JSON.
- Controller викликає Service, бо логіка має бути там.
- Controller повертає відповідь клієнту (зазвичай JSON).

Якщо сервіс — це “мозок”, то контролер — це “диспетчер”: прийняв запит → передав у правильне місце → віддав результат.

### 2) REST API: що це (дуже коротко і по суті)

REST — це стиль побудови API, де ми працюємо з ресурсами. Тут ресурс — це користувачі: /users.

- GET — отримати дані (читання)
- POST — створити нові дані (додавання)
- PUT/PATCH — оновити
- DELETE — видалити

На цій практичній ми робимо базові 2 операції: читання всіх і створення нового користувача.

### 3) Розбір анотацій контролера по скріну

@RestController — каже Spring: “це REST-контролер”.

- Spring створить bean цього класу.
- Методи будуть повертати дані напряму у відповідь (зазвичай JSON), а не HTML-сторінки.

@RequestMapping("/users") — базовий шлях для всіх методів у класі.

- Тобто всі маршрути всередині контролера будуть починатися з /users.

Важливо для студентів: @RequestMapping("/users") + @GetMapping = GET /users
@RequestMapping("/users") + @PostMapping = POST /users

### 4) Dependency Injection у контролері (як і в сервісі)

Контролер не створює сервіс вручну. Він отримує його через конструктор:

private final UserService userService; public UserController(UserService userService) { this.userService = userService; }

- Spring створює UserService і “вколює” його в контролер.
- final — сервіс не змінюється під час роботи.

### 5) Ендпоінт №1: GET /users

@GetMapping public List<User> getAllUsers() { return userService.getAllUsers(); }

- @GetMapping означає: метод викликається, коли приходить HTTP GET.
- Шлях береться з @RequestMapping("/users"), тому це GET /users.
- Метод повертає List<User> — Spring перетворює це у JSON.

hooking для уваги студентів: “ви повертаєте Java-об’єкти, а клієнт бачить JSON”.

Приклад відповіді (умовно):

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

### 6) Ендпоінт №2: POST /users

@PostMapping public User createUser(@RequestBody User user) { return userService.createUser(user); }

- @PostMapping — метод викликається, коли приходить HTTP POST.
- @RequestBody — взяти тіло запиту (JSON) і перетворити в Java-об’єкт User.
- Метод повертає створеного користувача (часто вже з id після збереження).

Приклад запиту в Postman:

POST http://localhost:8080/users Content-Type: application/json { "name": "John", "email": "john@example.com" }

Приклад відповіді (умовно):

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

### 7) Як Spring “робить JSON” (щоб пояснити простими словами)

Spring використовує JSON-бібліотеку (зазвичай Jackson), яка:

- вміє перетворити Java-об’єкт у JSON (серіалізація);
- і JSON у Java-об’єкт (десеріалізація).

Ключова умова: щоб JSON правильно складався, об’єкт має мати поля + геттери/сеттери (або record), інакше дані “не вийдуть назовні”.

### 8) Чому контролер має бути “тонкий” (важливий принцип)

Контролер не повинен:

- писати складну логіку (if-else на 50 рядків);
- лазити напряму в базу (викликати repository напряму);
- приймати рішення бізнес-рівня (“можна чи не можна створити користувача”).

Контролер повинен:

- прийняти дані з HTTP (path/body/query);
- викликати сервіс;
- повернути відповідь.

Це дисципліна, яка відрізняє “пет-проєкт на коліні” від нормального коду, який переживе рік розвитку.

### 9) Що буде далі (логічне продовження)

- Додати валідацію (наприклад, @Valid + Bean Validation).
- Додати ендпоінти: GET /users/{id}, PUT/PATCH /users/{id}, DELETE /users/{id}.
- Додати правильні HTTP-статуси (201 Created, 400 Bad Request, 404 Not Found).

Підсумок: ми створили REST-контролер, який публікує API для користувачів. Тепер клієнт може працювати з нашою системою навіть без frontend — через HTTP-запити (Postman/браузер).