스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다. API 예외 처리 HTML 페이지의 경우 그에 맞는 오류 페이지만 있으면 대부분의 문제를 해결할 수 있지만, API의 경우 고려해야 할 점이 더 많다. 오류 페이지는 단순히 클라이언트에게 오류 화면을 보여주고 끝이지만, API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고 JSON으로 데이터를 내보내야 한다. @RequestMapping 애노테이션의 produces 옵션을 MediaType.APPLICATION_JSON_VALUE으로 설정하면, HTTP 헤더의 Accept 값이 application/json일 때만 해당 메서드를 호출하게 된다. 스프링 부트 기본 오류 처리 스프링 부트가 제공하는 기본 오류 방식(BasicErrorController..

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다. 서블릿 예외 처리 - 예외 처리 방식 스프링이 아닌 순수 서블릿 컨테이너는 다음 두 가지 방식으로 예외 처리를 지원한다. 1. Exception(예외) 1-1. 자바의 메인 메서드를 직접 실행하는 경우 실행 도중에 예외를 잡지 못하고 처음 실행한 메인 메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료된다. 1-2. 웹 애플리케이션 웹 애플리케이션은 사용자 요청 별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 그런데 만약 애플리케이션 내에서 예외를 잡지 못하고 서블릿 밖으로까지 예외가 전달되면 WAS까지 예외가 전달되고, WAS가 기본으로 제공하는 오류 화면이 나타난다. 이 경우 HTTP 상태 코드가 500을 ..

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다. 공통 관심 사항 '로그인 처리(1) - 쿠키, 세션'에서 정의한 요구사항에 따르면 로그인을 한 사용자만 상품 관리 페이지에 들어갈 수 있어야 한다. 하지만 상품 관리 페이지의 URL을 직접 호출하면 로그인을 하지 않은 사용자도 접속할 수 있다는 문제점이 존재한다. 상품 관리 컨트롤러에서 로그인 여부를 체크하는 로직을 일일이 작성할 수도 있지만, 등록/수정/삭제/조회 등 모든 컨트롤러 로직에 공통으로 로그인 여부를 확인해야 하며 로그인과 관련된 로직이 변경될 때마다 작성한 모든 로직을 다 수정해야 하는 가능성이 존재한다. 이렇게 애플리케이션 여러 로직에서 공통으로 관심이 있는 부분을 '공통 관심사'라고 하는데, 해당 상황에서의 공통 관심사는 '인증'이..

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다. 로그인 요구사항 로그인 처리 파트 학습은 아래 요구사항을 구현하는 과정을 통해 이루어진다. 1. 로그인 전 홈 화면에는 회원가입과 로그인 버튼이 존재한다. 2. 로그인 후 홈 화면에는 회원 이름, 상품 관리 버튼, 로그아웃 버튼이 존재한다. 3. 로그인 사용자만 상품에 접근하고, 관리할 수 있다. 만약 로그인하지 않은 사용자가 상품 관리에 접근할 경우 로그인 화면으로 이동한다. 기본 로그인 처리 로그인 컨트롤러는 서비스 로직을 호출하여 로그인에 성공하면 홈 화면으로 이동하고, 로그인에 실패하면 BindingResult의 reject() 메서드를 사용해서 ObjectError를 생성한다. 그리고 정보를 다시 입력하도록 로그인 폼을 뷰 템플릿으로 사용하..

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다. Bean Validation이란 검증 애노테이션과 여러 인터페이스를 모은 기술 표준으로, 값의 비어있는 여부나 범위를 검증하는 것과 같이 일반적인 로직을 검증할 때 모든 프로젝트에 적용할 수 있게 공통화하고 표준화한 것이다. 해당 라이브러리를 사용하기 위해서는 build.gradle에 다음과 같이 의존관계를 추가해 주면 된다. implementation 'org.springframework.boot:spring-boot-starter-validation' 검증 애노테이션은 다음과 같이 적용할 수 있다. @NotBlank 빈 값인 경우 혹은 공백만 있는 경우를 허용하지 않는다. @NotNull null을 허용하지 않는다. @Range(min = 10,..

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다. 검증 컨트롤러의 중요한 역할 중 하나는 HTTP 요청이 정상인지 검증하는 것이다. 클라이언트 검증만으로는 조작의 가능성이 존재하기 때문에 보안에 취약하고, 서버만으로 검증하면 즉각적인 고객 사용성이 떨어진다. 따라서 둘을 적절히 섞어 사용하되 최종적으로 서버 검증을 거치도록 설계해야 한다. 검증 직접 처리 로직 1. Map errors = new HashMap();을 선언하여 오류를 보관할 변수를 지정하고 검증 시 오류가 발생하면 오류가 발생한 필드명을 key로, 오류 메시지를 value로 저장한다.(오류 원인이 특정 필드가 아니라 필드 범위를 넘어서는 오류라면 globalError를 key로 사용한다.) 이후 뷰에서 해당 데이터를 가지고 사용자에게..

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다. 메시지 / 국제화 메시지 기능은 다양한 메시지를 한 곳에서 관리하도록 하는 기능을 일컫는다. 여러 화면에 보이는 상품명, 가격 등을 일일이 하드코딩한 상황에서 이후에 단어를 수정해야 하는 경우가 발생한다면 관련된 파일을 전부 고쳐야 하는 번거로움이 발생한다. 대신 메시지 관리용 파일에 메시지를 정의하고 가져다 쓰는 방식을 채택한다면 관리 파일만 수정하면 된다. 이러한 메시지 파일을 각 나라의 언어별로 관리하면 서비스를 국제화할 수 있다. HTTP accept-language 헤더 값을 사용하거나 사용자가 언어를 선택하는 등 접근 국가를 인식하여 해당 국가의 언어로 제공하게 된다. 스프링 메시지 소스 설정 spring.messages.basename=..

스프링 MVC 1편의 강의 내용을 정리한 포스팅입니다. 요청 매핑 매핑 정보 클래스에 @Controller를 추가할 경우 반환 값이 String이면 뷰 이름으로 인식되는 반면, @RestController의 경우 뷰 이름이 아닌 해당 문자열을 HTTP 바디에 바로 입력하게 된다. 더불어 @RequestMapping을 이용함으로써 특정 URL과 매핑이 가능한데, 여러 개의 URL을 배열로 등록함으로써 다중 설정도 가능하다. HTTP 메서드 @RequestMapping에 메서드 속성을 추가하지 않으면 메서드에 관계없이 호출되지만, @RequestMapping(value = "/mapping-get", method = RequestMethod.GET)와 같이 속성을 지정할 경우 메서드가 일치하지 않을 때 40..