[데브코스] Spring Boot REST API 실습

이번 시리즈는 Spring Boot로 REST API를 직접 구현하면서컨트롤러/서비스/JPA/Validation/Jackson 흐름을 단계별로 익히는 실습입니다.1강은 “기능 구현 전 프로젝트 세팅”이 핵심이라서,실습을 그대로 따라가기 위한 Gradle 의존성 + ap

UI 방식 선택(Thymeleaf vs React) + JPA/Validation 추가 + 샘플 데이터 생성이번 글은 2강과 3강 내용을 한 번에 정리합니다.2강: UI를 Thymeleaf(서버 렌더링)로 할지, React(클라이언트 렌더링)로 할지에 따라스프링부트 구

Jackson, 순환참조, 게시글 목록/단건 조회 API 구현이번 글에서는 Spring Boot REST API 실습 4강과 5강 내용을 한 번에 정리한다.게시글 목록 조회와 단건 조회 API를 구현하면서Jackson의 역할, 엔티티 순환참조 문제, @RestContr

REST API 구현에서 API 버저닝을 하는 이유 이번 글에서는 REST API 구현 시 왜 API 버저닝이 필요한지를 정리한다. 특히 Thymeleaf 방식과 REST API 방식의 차이, 그리고 프론트엔드 개발자와의 협업 관점에서 API 버저닝이 왜 중요한 개념

데브코스 Spring Boot REST API 실습을 진행하면서“프론트엔드 개발자의 요구사항을 엔티티에 바로 반영하면 안 된다”는 것을 이번 글은 그 과정을 정리한 기록이다.프론트엔드 개발자와 협의 중 이런 요청이 나왔다.JSON 응답에서 이름만 바꾸면 되는 것처럼

이번 글은 데브코스 Spring Boot REST API 실습 8강 내용을 정리한 글이다.8강에서는 엔티티를 그대로 API 응답으로 반환하지 않고,DTO(PostDto)를 도입하는 과정을 3단계 실습으로 나누어 진행했다.이 강의의 핵심은DTO를 “만드는 것”보다, DT

이번 글은 데브코스 Spring Boot REST API 실습 9강 내용을 정리한 글이다.9강에서는 기존에 사용하던 PostDto 클래스를 Java record로 변경하고,DTO를 더 간결하고 명확하게 표현하는 방법을 다룬다.또한 프론트엔드 개발자의 요구사항 변경을엔티

이번 글은 데브코스 Spring Boot REST API 실습 10강 내용을 정리한 글이다.10강에서는 게시글에 달린 댓글 다건 조회 / 단건 조회 API를 구현하며,@OneToMany 연관관계와 LAZY 로딩이 실제로 언제 쿼리를 발생시키는지를 함께 학습한다.10강의

이번 글은 데브코스 Spring Boot REST API 실습 11강 내용을 정리한 글이다.11강에서는 댓글 삭제 API를 구현하면서,왜 JPA에서 @Transactional이 없으면 삭제가 DB에 반영되지 않는지를 직접 체험한다.또한 orphanRemoval = tr

이번 글은 데브코스 Spring Boot REST API 실습 12강 내용을 정리한 글이다.12강은 새로운 기능을 구현하는 강의라기보다는,댓글 삭제 API가 왜 동작했고, 왜 동작하지 않았는지를JPA 내부 동작 관점에서 정리하는 강의였다.핵심 키워드는 다음 세 가지다.

이번 글은 데브코스 Spring Boot REST API 실습 13강 내용을 정리한 글이다.13강에서는 새로운 API 기능을 추가하기보다는,REST API 응답 설계 관점에서 중요한 원칙을 다룬다.특히 다음 질문에 대한 답을 다룬다.왜 조회 API와 삭제 API의 응답

이번 글은 데브코스 Spring Boot REST API 실습 14강 내용을 정리한 글이다.14강에서는 본격적으로 공통 응답 객체(RsData) 를 도입하면서,REST API에서 “어떤 응답에 공통 포맷이 필요한가?” 를 설계 관점에서 다룬다.14강의 핵심 메시지는 명

이번 강의에서는 기존에 사용하던 RsData(resultCode, msg) 구조를 확장하여resultCode와 msg만으로는 표현하기 어려운 부가 데이터를 함께 응답으로 내려주는 방법을 다룬다.특히 프론트엔드와의 협업 관점에서왜 data 필드가 필요한지,그리고 현재 구

이번 강의에서는 글 삭제 API 구현을 진행하면서,기존에 도입했던 RsData 구조의 한계를 직접 체감하게 된다.결론적으로는👉 글 관련 응답 전용 클래스인 ForPostRsData를 새로 도입하게 되었고,이 과정 자체가 “왜 응답 구조를 처음부터 범용으로 설계해야 하

이번 강의에서는 이전 강의(16강)에서 도입했던ForPostRsData 클래스를 제거하고,다시 RsData 하나로 응답을 통합하는 방향으로 구조를 변경한다.다만, 그 과정에서RsData의 data 필드 타입을 Object로 변경하게 되고,이 선택이 완벽한 해답은 아니라

이번 강의(18강)에서는 드디어 RsData를 제네릭(Generic) 으로 바꾸면서이전 강의에서 임시로 사용했던 Object 타입을 제거한다.이걸로 인해:글 응답 / 댓글 응답 모두 RsData 하나로 통일 가능타입 안정성 확보도메인별 RsData 클래스(ForPost

이번 강의(19강)는RsData<T> 구조를 실제로 어떻게 써야 하는지를 아주 디테일하게 다듬는 강의였다.단순히 문법을 배우는 게 아니라,언제 Void를 써야 하는지왜 제네릭을 생략해도 에러가 안 나는지record에서 생성자를 어떻게 써야 하는지까지 자연스럽게 이

이번 글에서는 Spring Boot REST API 실습 20강 내용을 정리한다.그동안 구현해온 API를 Postman으로 직접 호출하며 검증해보는 단계다.이번 강의의 핵심은 “프론트가 없어도 REST API는 충분히 검증할 수 있다”라는 점을 체감하는 것이다.글 다

이번 강의(21강)는 기능 추가가 아니라 API 설계를 REST답게 수정하는 단계였다.기존에는 개발 편의를 위해 삭제를 GET 요청으로 처리했지만,이번 강의에서는 HTTP Method의 의미에 맞게 DELETE로 변경했다.그리고 강의 말미에 자연스럽게 이런 질문이 떠올

이번 강의(22강)에서는 글 작성 API를 POST 요청으로 구현하고,요청 본문을 JSON 형태로 전달하는 방식까지 다뤘다.이전 강의에서 정리했던 RsData 응답 구조를 그대로 유지하면서,요청 DTO를 record 형태로 컨트롤러 내부에 선언하는 방식도 새롭게 등장했

이번 강의에서는 REST API 환경에서의 유효성 검증 전략에 대해 다뤘다.특히 아래 질문이 핵심이다.프론트에서 이미 다 검증하는데 백엔드에서 또 해야 하나?@Valid는 쓰는데 왜 BindingResult는 거의 안 쓰는가?BindingResult를 쓰면 오류가 안

이번 강의에서는 기능적인 변화보다는REST API 설계 관점에서의 네이밍과 요청 처리 방식을 정리하는 시간이었다.겉보기엔 변경 사항이 적어 보이지만,REST API를 제대로 이해하기 위해서는 꼭 짚고 넘어가야 할 내용이다.Form이라는 이름은 보통 HTML form 기

이번 강의에서는“응답 데이터가 점점 복잡해질 때, 어떻게 구조를 잡아야 하는가?” 를 다뤘다.핵심은 하나다.RsData의 data 필드는 하나지만그 하나 안에 무엇을 담느냐는 설계의 문제다.강의는 총 4번의 커밋을 통해List → Map → 전용 Response Bod

이번 강의에서는 REST API 응답 코드(HTTP Status Code) 에 대해 다룬다.특히 “게시물 작성 성공 시 200으로 응답해도 되는가?” 라는 현실적인 질문을 중심으로,실무에서의 기준과 타협점을 정리했다.게시글 작성 API를 구현하고 Postman으로 테스

이번 강의의 핵심은 이 문장 하나로 요약된다.RsData의 resultCode와 HTTP Status Code는 완전히 별개다.이걸 이해하지 못하면“분명 201-1로 바꿨는데 왜 Postman은 아직도 200이야?”라는 혼란이 계속 생긴다.이전까지 우리는 이런 응답을

이번 강의는 지금까지 배운 내용들이 한 번에 정리되는 느낌의 강의였다.핵심 키워드는 딱 세 가지다.ResponseEntity 제거RsData.resultCode 기준으로 HTTP 상태 코드 설정AOP(ResponseAspect)로 후처리27강에서 우리는 이런 코드를 사

이번 강의는 기술 하나를 배우는 느낌보다는지금까지 배운 것들을 관통하는 사고방식을 정리해주는 강의였다.핵심은 크게 두 가지다.AOP를 왜 쓰는가?개발 공부를 어떻게 해야 효율적인가?AOP를 한 문장으로 정리하면 이거다.AOP는 “룰에 의한 코드 적용”이다.예를 들어 이

이번 강의는“DTO를 언제, 왜, 어떻게 나누어 써야 하는지”가 아주 명확하게 정리된 강의였다.이전까지는 DTO를 만들긴 했지만 이게 언제 필요한지어디까지 만들어야 하는지안 만들어도 되는 경우는 언제인지 가 좀 애매했는데,30강에서 이 기준이 깔끔하게 정리됐다.핵심

이번 강의는 기능 하나를 추가하면서“아, 이래서 이 필드가 존재하는구나”가 명확해지는 강의였다.핵심은 세 가지다.글 수정 API(PUT) 구현RsData 생성자 버그 수정statusCode 필드의 존재 이유 이해여기서 눈에 띄는 부분이 있다.JSON 응답으로는 절대 내

이번 강의는 앞에서 구현했던 글 수정 API를 그대로 확장해서댓글 수정 API를 구현하는 강의였다.구조도 흐름도 이미 익숙한 패턴이라“아, 이제 이건 손에 익었다”는 느낌이 드는 단계다.댓글 수정은 PUT 요청입력값은 JSON → @RequestBody유효성 검사는 @