Пошук уроків, статей та іншого контенту
@Controller та декоратори маршрутів — тонкий HTTP-шар, що делегує роботу сервісам.
Контролер відповідає за прийом HTTP-запиту, витягування потрібних даних (параметри маршруту, тіло запиту, заголовки) і повернення відповіді — те саме, за що у звичайному Node.js без фреймворка (курс Node.js) відповідав би колбек createServer, розписаний вручну через перевірки req.method/req.url.
import { Controller, Get, Post, Body, Param } from "@nestjs/common";
import { CatsService } from "./cats.service";
@Controller("cats") // усі маршрути цього контролера починаються з /cats
export class CatsController {
constructor(private readonly catsService: CatsService) {}
@Get()
findAll() {
return this.catsService.findAll(); // контролер делегує роботу сервісу
}
@Get(":id")
findOne(@Param("id") id: string) {
return this.catsService.findOne(id);
}
@Post()
create(@Body() createCatDto: { name: string; age: number }) {
return this.catsService.create(createCatDto);
}
}Замість ручного парсингу об'єкта запиту (як у прикладі з голим http-модулем у курсі Node.js), NestJS дає декоратори, що напряму витягують потрібну частину запиту як типізований параметр методу:
@Param('id') — значення динамічного сегмента маршруту (:id).
@Query('search') — значення параметра рядка запиту (?search=...).
@Body() — розпарсене тіло запиту (типово JSON).
@Headers('authorization') — значення конкретного заголовка запиту.
Хороша практика — тримати логіку контролера мінімальною: витягнути дані з запиту, викликати відповідний метод сервісу, повернути результат. Валідація, звернення до бази даних, бізнес-правила належать сервісу (наступний урок), а не контролеру — так само, як у Next.js Server Actions варто валідувати вхідні дані на сервері, а не лише в UI-шарі (курс Next.js).
Практичний тест: якщо метод контролера довший за кілька рядків або містить умовну бізнес-логіку («якщо користувач вже має 5 котів — відмовити»), це майже завжди ознака, що частину коду варто перенести в сервіс.
За замовчуванням NestJS повертає 200 (чи 201 для POST) і серіалізує повернуте значення методу в JSON автоматично — явно керувати статус-кодом чи заголовками можна декоратором @HttpCode() або через об'єкт Response, коли потрібна нестандартна поведінка.
Писати бізнес-логіку (звернення до бази даних, обчислення, валідацію правил) прямо в методі контролера — ускладнює тестування й порушує розділення відповідальності між HTTP-шаром і бізнес-логікою.
Забути @Body()/@Param() і намагатись читати дані запиту напряму, як у голому Express/http — без декоратора NestJS не знає, звідки саме брати значення параметра методу.
Дублювати перевірку типів вручну в тілі методу замість використання Pipes (окремий урок) для валідації й трансформації вхідних даних декларативно.
Контролер (@Controller) — тонкий HTTP-шар: приймає запит, витягує потрібні дані через декоратори параметрів (@Param, @Query, @Body), делегує реальну роботу сервісу і повертає результат. Бізнес-логіка, валідація й звернення до бази даних належать сервісам, а не контролерам — контролер лишається якомога простішим перекладачем між HTTP і рештою застосунку.