Nestjs Controllers

NestJS Controllers & Routing

Controllers are the entry point of a NestJS HTTP application: they bind routes to handlers, extract and validate request data, and shape responses. The framework gives you a lot for free (status codes, serialization, validation, versioning) — but only when you stay on the idiomatic path. These rules keep controllers thin, type-safe, and aligned with NestJS v10/v11 conventions so you don't accidentally opt out of framework features.

When to Apply

• Writing or reviewing classes decorated with @Controller
• Adding route handlers with @Get, @Post, @Put, @Patch, @Delete
• Extracting request data via @Param, @Query, @Body, @Req, @Res
• Defining DTO classes for request bodies
• Controlling response status codes and serialization
• Designing RESTful resource paths or versioning a public API

Rules

• thin-controllers — CRITICAL — controllers only route and validate; business logic lives in services
• dto-request-bodies — HIGH — typed DTO classes for @Body, never any
• async-handlers-return-promises — MEDIUM — return promises/observables and let Nest resolve them
• param-decorators-over-req — HIGH — use @Param/@Query/@Body, avoid raw @Req/@Res
• restful-resource-routing — MEDIUM — consistent resource paths, plural nouns, proper HTTP verbs
• http-status-codes — MEDIUM — use @HttpCode for non-default statuses (e.g. 201/204)
• serialize-responses — CRITICAL — ClassSerializerInterceptor + @Exclude to hide sensitive fields
• api-versioning — LOW — enableVersioning for evolving public APIs

How to Use

Read individual rule files in rules/.