There is one line of code that quietly ruins more Spring Boot APIs than any other: return userRepository.findById(id).orElseThrow(); It compiles. It returns 200 OK. It ships. And it hands the entire internet your BCrypt password hash, your account-lock state, and your failed-login counter — because Jackson serialises every field it can reach, and your @Entity was never designed to be read by strangers. In Episode 4 of Building Instagram's Authentication Backend , we build the wall that stops this: DTOs . Ten of them, in one file, guarding nine endpoints. This article is the written companion — every annotation, every design decision, and the exact reason request DTOs and response DTOs are not the same kind of object. What you'll build One file — dto/AuthDtos.java — containing 7 request DTOs (validated input) and 3 response DTOs (controlled output), wired to the GlobalExceptionHandler we built in Episode 3. What Is a DTO in Spring Boot? A DTO (Data Transfer ...
In Episode 2 we poured the foundation — the project, every dependency, and all the configuration in one place. Before we build a single feature on top of it, we build the part that most tutorials skip entirely: error handling . Episode 3 is about making every failure look the same. When something goes wrong in an API — a bad password, a duplicate email, an expired token — the client should get back one predictable shape, with the right HTTP status and a stable error code it can actually program against. No stack traces leaking to users. No endpoint returning 200 OK with an error buried inside. Today we build that backbone: a response envelope, a set of typed exceptions, and one handler that translates all of them. What you’ll learn in Episode 3 This episode is the first real code of the series — and it’s deliberately unglamorous, because a consistent error contract is what makes everything after it pleasant to build. By the end you...
.png)
.png)