Tag: spring-boot
All the articles with the tag "spring-boot".
-
Spring Boot #2 — REST API 로 CRUD · 레이어드 아키텍처 · 전역 예외 처리기
Spring Boot #1 (첫 실행 · DI) 에 이어 #2 는 REST API 로 CRUD. REST 는 URL + HTTP 메서드의 조합이라는 정의부터 정리 (GET/POST/PUT/DELETE), 컨트롤러에 @GetMapping · @PostMapping · @PutMapping · @DeleteMapping 붙여서 todos CRUD 완성. curl 옵션 (-X 메서드 · -H 형식 · -d 데이터) 정리 및 5스텝 curl 흐름 검증 (생성 → 전체 조회 → 수정 → 삭제 → 최종 조회). 컨트롤러가 로직까지 다 들고 있으니 서비스로 분리 → 레이어드 아키텍처 (Controller = 요청/응답 / Service = 로직 / Repository = 저장). 예외 처리는 커스텀 예외 → 404 응답, 그리고 전역 예외 처리기 (Global Exception Handler) 를 두면 컨트롤러는 그냥 throw 만 하고 응답 매핑은 처리기가 담당 — 자바 #3 편에서 배운 "throw 는 강제 전파" 계약성이 실전으로 확장됨. 시행착오 2건 (참조 클래스 없이 서버 켜기 요청 · 라이브러리 추가 전 패키지 작성) 은 학습 지침에 반영해서 다음부터 재발 방지.
-
Spring Boot #1 — 첫 실행 (bootRun · Tomcat 내장) · @RestController · 의존성 주입 감 잡기
자바 #3 (예외 · 동시성 · Gradle) 을 매듭짓고 오늘부터 Spring Boot. Spring Initializr 로 hello-spring 프로젝트를 뽑고 ./gradlew bootRun 으로 실행 — 터미널이 "80% EXECUTING" 에서 멈춘 것처럼 보이는데 사실은 이미 서버가 8080 에 뜬 상태 (Gradle daemon 이 프로세스를 붙잡고 있어서 진행률이 그렇게 표시됨). Spring Boot 는 Tomcat 을 내장하고 있어서 별도 WAS 설치 없이 8080 이 뜨는 것. 엔드포인트가 없으면 8080 에 접속해도 에러 페이지가 나오고, @RestController + @GetMapping 으로 경로를 지정해야 응답이 붙는다. 이후 의존성 주입 (DI) 감 잡기 — 컨트롤러가 서비스 인스턴스를 new 로 만들지 않는데도 서비스가 주입되는 이유는 스프링이 시작 시 @Service 클래스의 인스턴스를 하나 만들어 빈 (Bean) 으로 보관하고 있다가 컨트롤러 생성자에 자동으로 꽂아주기 때문. 자바 #1 부터 이어진 인터페이스 감각 — 구현체를 모르고 넘겨받아서 쓰는 계약성 — 이 스프링에서 자동화된 형태. 결합도가 낮아지고 테스트가 쉬워지는 이유가 여기 있다.