Tag: spring-boot
All the articles with the tag "spring-boot".
-
Spring Boot #2 — CRUD with REST API · Layered Architecture · Global Exception Handler
Following Spring Boot #1 (first run · DI), #2 covers CRUD with REST API. Starting from the definition that REST is a combination of URL + HTTP method (GET/POST/PUT/DELETE), I completed todos CRUD by attaching @GetMapping · @PostMapping · @PutMapping · @DeleteMapping to the controller. I organized curl options (-X method · -H format · -d data) and verified the flow with a 5-step curl sequence (create → list all → update → delete → final check). Since the controller was holding all the logic, I split it into a service → layered architecture (Controller = request/response / Service = logic / Repository = storage). For exception handling: custom exception → 404 response, and with a Global Exception Handler in place, the controller just throws while the handler takes care of the response mapping — extending into practice the "throw forces propagation" contract I learned in the Java #3 post. Two trial-and-error incidents (trying to start the server without a referenced class present · writing package code before adding the library) got folded into my study guidelines to prevent recurrence.
-
Spring Boot #1 — First Run (bootRun · Embedded Tomcat) · @RestController · Getting a Feel for Dependency Injection
Wrapping up Java #3 (Exceptions · Concurrency · Gradle), I'm starting Spring Boot today. I pulled a hello-spring project from Spring Initializr and ran it with ./gradlew bootRun — the terminal looks stuck at "80% EXECUTING" but the server is actually already up on port 8080 (the Gradle daemon is holding onto the process, which is why the progress bar shows that way). Spring Boot has Tomcat embedded, so port 8080 comes up without installing a separate WAS. With no endpoint defined, hitting 8080 gives an error page — you need @RestController + @GetMapping to specify a path before a response is attached. Then, getting a feel for dependency injection (DI) — the reason a service gets injected into a controller without the controller ever calling new on it is that Spring creates one instance of the @Service class at startup, keeps it as a bean, and automatically plugs it into the controller's constructor. The interface sense I've been building since Java #1 — the contractual nature of using something handed to you without knowing its implementation — shows up here in an automated form within Spring. This is exactly why coupling goes down and testing gets easier.