Part 8 of Building Instagram's Authentication Backend . If you're just joining, the repo is here and you can catch the earlier parts on the YouTube playlist . We built an engine with no ignition Here's where we actually stood after seven parts of this series. We had a fully working AuthService — register, login, refresh, the works. We had a security layer sitting on top of it, filtering every request, deciding who's allowed where. We had entities, repositories, DTOs, a whole exception-handling backbone. And none of it had a URL. Not one line of that code could be reached from outside the JVM. No curl command, no Postman request, nothing. It's a strange feeling to have written that much working logic and still not be able to actually call any of it. So that's what this part is about — wiring up the front door. The controller, and why it's boring on purpose Here's the register endpoint, in full: @PostMapping ( "/registe...
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 ...