Back to the Basics Back to the Basics

Spring MVC의 예외 처리 흐름과 함께 @ExceptionHandler, @ControllerAdvice, ResponseEntityExceptionHandler를 실제 사례와 함께 정리합니다. 실무에서 API 오류 응답을 체계적으로 처리하는 전략을 배웁니다. 예외는 반드시 발생한다 – 그래서 설계가 중요하다 API를 만들다 보면 잘못된 요청, 인증 실패, 리소스 없음 등 다양한 예외가 발생합니다.문제는 예외가 발생했을 때 클라이언트에게 어떻게 응답할지 전략이 없으면 다음과 같은 일이 생긴다는 거죠. 500 Internal Server Error가 그대로 노출됨HTML 에러 페이지가 REST 응답에 노출됨오류 메시지에 스택트레이스가 그대로 출력됨 이런 건 단순히 보기 안 좋을 뿐 아니라 보안 문제..

Spring MVC로 웹 애플리케이션을 개발하다 보면 컨트롤러에서 데이터를 뷰에 전달하거나, REST API 형태로 JSON 응답을 줄 일이 많습니다. 이때 자주 마주치는 것이 바로 Model, ModelAndView, 그리고 ResponseEntity입니다. 세 가지 모두 응답 데이터를 처리하는 방식이지만, 각각의 목적과 사용 방식에는 뚜렷한 차이가 있습니다. 오늘은 이 세 가지의 차이점과 실제 현업에서는 어떤 기준으로 선택하는지를 집중적으로 짚어보겠습니다. Model – 뷰(View) 렌더링 중심의 데이터 전달자 Model은 전통적인 MVC 패턴에서 “데이터를 뷰로 넘기는” 역할에 충실한 객체입니다. 주로 JSP, Thymeleaf 같은 템플릿 뷰에서 사용됩니다.@GetMapping("/hello"..

스프링에서 자주 사용하는 @Controller와 @RestController, 그리고 @RequestMapping 애노테이션이 DispatcherServlet과 어떻게 연결되고 처리되는지 흐름 중심으로 설명합니다. @Controller와 @RestController는 뭐가 다른가요? 가장 간단히 정리하면:애노테이션반환 방식용도@Controller뷰 이름웹 페이지 응답 (HTML)@RestControllerHTTP 본문(JSON 등)API 응답즉, @RestController는 사실상 아래 두 가지의 합성입니다.@RestController== @Controller + @ResponseBody DispatcherServlet과 어떻게 연결될까? Spring MVC가 내부적으로 요청을 처리할 때, Dispa..

Spring MVC에서 요청이 들어오면 어떤 경로를 따라 응답이 만들어질까요? DispatcherServlet을 중심으로, HandlerMapping, Controller, ViewResolver까지의 흐름을 자연스럽게 정리합니다.Spring MVC의 진짜 시작점은?우리는 보통 컨트롤러부터 코드를 쓰기 시작합니다.@GetMapping("/hello")public String hello() { return "hello";}근데 정말 이게 전부일까요?이렇게 작성된 코드는 어떻게 실행되고, 어떻게 우리가 작성한 뷰 이름을 찾아가는 걸까요?그 중심에는 바로 DispatcherServlet이 있습니다.사실상 Spring MVC의 모든 요청은 DispatcherServlet을 거쳐서 흐릅니다.Dispatche..