스프링 MVC

스프링 웹 MVC에 들어가기에 앞서, 웹 애플리케이션에 대해 정리해보자.웹 상에서 데이터를 주고 받을 때, 사용하는 프로토콜은 HTTP 이다.HTTP 프로토콜 스펙에 맞게, 요청 또는 응답을 작성하고, 이를 주고 받음으로써 웹을 통해 통신한다.웹 서버는 HTTP를 기반

이전의 글에서 서블릿에 대해서 설명했기에, 서블릿에 대한 이론적인 내용은 생략한다.이번 글에서는 실제 서블릿이 WAS 상에서 어떻게 동작하는지에 초점을 맞춰보자.스프링 부트는 @ServletComponentScan이라는 annotation으로 서블릿을 직접 등록해서 사

WAS가 필요했던 근본적인 이유가 무엇인가? 그건 바로 '동적 리소스' 를 제공하기 위함이었다.따라서, 개발자는 자바에서 제공하는 서블릿을 이용한 프로그램 코드로 상황에 따라 변하는 동적 리소스를 제공할 수 있게 되었다. 또, 서블릿을 지원하는 아파치 톰캣 같은 WAS

이전 글에서, 프론트 컨트롤러 패턴을 도입하면 공통 처리에 대한 부분들을 해결할 수 있다고 했었다.이게 무슨 말일까? 그림으로 확인하면 이해하기 쉽다. 아래의 2개의 그림을 보자. 첫번째 그림은 프론트 컨트롤러 패턴을 적용하기전의 그림, 즉 저번 글에서 단순하게 MVC

스프링 MVC의 구조는 아래의 그림과 같다.동작 순서는 다음과 같다. 이전 글에 마지막에 복기했던 내용과 거의 흡사하다.HTTP 요청이 DispatcherServlet에 도착핸들러 조회 - 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러 조회핸들러 어댑터 조회 - 핸들

스프링 MVC가 제공하는 주요기능들에 대해 정리해보자. 개발적인 측면에서 자주 사용할 수 밖에 없는 기능들을 위주로 정리하겠다. @Controller 와 @RestController 스프링 MVC에서 Controller의 역할을 하는 클래스에 붙이는 annotatio

웹 애플리케이션을 개발하다보면, 여러 페이지에서 동일하게 사용되는 단어나 문구들이 있다.이런 단어나 문구들을 HTML 같은 정적인 영역에 하드코딩 해놓을 경우 추후에 변경 사항 발생 시 여러군데에 반복적으로 있는 모든 단어, 문구들을 모두 수정해야한다. 그럴 바에는 프

검증은 웹 애플리케이션에서 필수적인 기능 중 하나이다. 검증이라는 단어 자체가 포함하고 있는 의미가 포괄적이기 때문에 구체적으로 어떤 검증을 말하는 것인지 감을 잡기가 쉽지않다. 스프링에서 말하는 검증이 무엇인지 알아보자.가장 쉬운 예시는 웹 애플리케이션에서 폼을 작성

이전 글에서는 스프링이 HTTP 요청을 통해 서버로 들어오는 데이터를 검증하는 방법에 대해 알아보았다.이런 검증 기능들을 매번 코드로 작성하는 것은 상당히 번거롭다. 특히 특정 필드에 대한 검증 로직은 대부분 빈 값인지 아닌지, 특정 크기를 넘는지 아닌지와 같이 매우

웹 애플리케이션을 개발하다보면, 애플리케이션의 여러 로직에서 공통적으로 관심을 갖게 되는 요소가 있다. (ex. 인증, 로깅, 전처리 등)이러한 공통 관심사는 스프링의 AOP(내부적으로 프록시 패턴 사용)나 디자인 패턴으로도 해결할 수 있지만, 웹과 관련된 공통 관심사

스프링 인터셉터도 서블릿 필터와 같이 웹과 관련된 공통 관심사를 효과적으로 해결할 수 있는 기술이다. 서블릿 필터가 서블릿이 제공하는 기술이라면, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이다. 둘다 웹과 관련된 공통 관심사를 처리하지만, 적용되는 순서와 범위,

웹 서비스에서는 잘못된 요청이 서버로 들어왔을 때, 서비스를 사용하는 사용자에게 요청이 잘못되었다는 것을 알려야한다. 하지만, 요청이 잘못되었다는 것을 어떤 방식으로 알려야할까?스프링이 없는 순수 서블릿 컨테이너, 즉 아파치 톰캣같은 WAS는 서블릿을 이용하기 때문에,

HTML 페이지의 경우, 예외가 발생했을 때 사용자에게 볼 수 있는 오류 페이지가 있으면 대부분의 문제를 해결할 수 있었다. 그런데 API의 경우에는 어떻게 해야할까? API는 사용자에게 직접 보여지는 HTML 페이지를 반환하는 것이 아니라, JSON 형태의 데이터를

스프링 MVC 컨트롤러에서는 메서드의 파라미터로 다양한 타입의 데이터를 받을 수 있다. 이게 가능했던 이유는 스프링의 ArgumentResolver가 메서드에 필요한 파라미터 값을 만들어서 넣어주기 때문이었는데, 그 때의 기억을 되살려보자. HTTP 요청 메시지로 넘어

HTTP를 이용하여 통신을 할 때, 보통의 경우 문자 데이터를 보내는 경우가 많다.만약, 문자 데이터가 아니라 파일 형태의 데이터를 보내고자한다면 어떻게 해야할까? 일반적으로 문자 데이터를 HTTP를 통해 보내는 방법으로는 쿼리 파라미터 형식의 GET 요청으로 요청 U