day61 🌕

장미·2022년 8월 13일

오늘의 성과

목록 보기

61/129

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 섹션 9 수강

+) 22. 08. 17. 추가

섹션 9. API 예외 처리 수강 완료!!

API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려줘야 한다.

스프링 부트 기본 오류 처리

BasicErrorController 코드

@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse
response) {}

@RequestMapping
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {}

errorHtml(): produces = MediaType.TEXT_HTML_VALUE ➡️ 클라이언트 요청의 Accept 헤더 값이 text/html인 경우에는 errorHtml()을 호출해서 view를 제공한다.
- produces = MediaType.APPLICATION_JSON_VALUE: 클라이언트가 요청하는 HTTP header의 Accept 값이 application/json일 때 해당 메서드가 호출된다. ➡️ 클라이언트가 받고 싶은 미디어 타입이 json이면 이 컨트롤러의 메서드가 호출된다.
error(): 그 외의 경우에 호출되고 ResponseEntity로 HTTP Body에 json 데이터를 반환한다.

스프링 부트가 제공하는 BasicErrorController는 HTML 페이지를 제공하는 경우에는 매우 편리하다.
하지만 API 오류 처리는 각 API마다 컨트롤러나 예외에 따라 서로 다른 응답 결과를 출력해야 할 수도 있다. 예를 들어서, 회원과 관련된 API에서 예외가 발생할 때의 응답과, 상품과 관련된 API에서 발생하는 예외에 따라 그 결과가 달라질 수 있다.
따라서 이 방법은 HTML 화면을 처리할 때 사용하는 것이 좋다.

HandlerExceptionResolver

컨트롤러(핸들러) 밖으로 던져진 예외를 해결하고, 동작 방식을 변경하고 싶으면 HandlerExceptionResolver를 사용하면 된다.

⬇️ ExceptionResolver 적용 전

ExceptionResolver 적용 전

⬇️ ExceptionResolver 적용 후

ExceptionResolver 적용 후

HandlerExceptionResolver 인터페이스

public interface HandlerExceptionResolver {
	ModelAndView resolveException(
	HttpServletRequest request, HttpServletResponse response,
    Object handler, Exception ex);
}

handler: 핸들러(컨트롤러) 정보
Exception ex: 핸들러(컨트롤러)에서 발생한 예외

ExceptionResolver가 ModelAndView를 반환하는 이유는 마치 try-catch를 하듯이, Exception을 처리해서 정상 흐름처럼 변경하는 것이 목적이기 때문이다.

ExceptionResolver 활용

예외 상태 코드 변환
예외를 response.sendError(xxx) 호출로 변경하여 서블릿에서 상태 코드에 따른 오류를 처리하도록 위임한다.
이후 WAS는 서블릿 오류 페이지를 찾아서 호출한다.
뷰 템플릿 처리
ModelAndView에 값을 채워서 예외에 따른 오류 화면을 뷰 렌더링하여 고객에게 제공한다.
API 응답 처리
HTTP 응답 바디에 직접 데이터를 넣는 것도 가능하다. 여기에 JSON으로 응답하면 API 응답을 처리할 수 있다.

정리
ExceptionResolver를 사용하면 컨트롤러에서 예외가 발생해도 ExceptionResolver에서 예외를 처리해 버린다. 따라서 예외가 발생하더라도 서블릿 컨테이너까지 전달되지 않고, 스프링 MVC에서 끝난다.
즉, 결과적으로 WAS 입장에서는 정상 처리가 된 것이다.

스프링이 제공하는 ExceptionResolver

ExceptionHandlerExceptionResolver
@ExceptionHandler를 처리한다. API 예외 처리는 대부분 이 기능으로 해결한다.
ResponseStatusExceptionResolver
HTTP 상태 코드를 지정한다.
예: @ResponseStatus(value = HttpStatus.NOT_FOUND)
DefaultHandlerExceptionResolver
스프링 내부에서 발생하는 예외를 처리한다.

@ExceptionHandler

@ExceptionHandler 예외 처리 방법
@ExceptionHandler 애노테이션을 선언하고, 해당 컨트롤러에서 처리하고 싶은 예외를 지정해 주면 된다.

다양한 예외
다음과 같이 다양한 예외를 한 번에 처리할 수 있다.

@ExceptionHandler({AException.class, BException.class})
public String ex(Exception e) {
   log.info("exception e", e);
}

예외 생략
@ExceptionHandler에 예외를 생략하면 메서드 파라미터의 예외가 지정된다.

@ExceptionHandler
public ResponseEntity<ErrorResult> userExHandle(UserException e) {}

ResponseEntity를 사용하면 HTTP 응답 코드를 프로그래밍해서 동적으로 변경할 수 있다.

@ControllerAdvice

@ExceptionHandler는 정상 코드와 예외 처리 코드가 하나의 컨트롤러에 섞여있다.
@ControllerAdvice 또는 @RestControllerAdvice를 사용하면 둘을 분리할 수 있다.

@ControllerAdvice는 대상으로 지정한 여러 컨트롤러에 @ExceptionHandler, @InitBinder 기능을 부여해 주는 역할을 한다.
@ControllerAdvice에 대상을 지정하지 않으면 모든 컨트롤러에 적용된다.
@RestControllerAdvice는 @ControllerAdvice와 같고, @ResponseBody가 추가되어 있다.

토픽 1개 - http vs https

+) 22. 09. 03. 추가!!

HTTP(Hypertext Transfer Protocol)

서로 다른 시스템들 사이에서 통신을 주고 받게 하는 가장 기본적인 프로토콜이다.
데이터를 서버 → 브라우저로 전송하는 용도로 가장 많이 사용한다.
HTTP는 서버에서 브라우저로 전송하는 정보가 암호화되지 않는다는 문제점이 있다.

HTTPS(Hypertext Transfer Protocol Secure)

HTTPS는 HTTP에 SSL(보안 소켓 계층)을 적용한 프로토콜이다.
SSL은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버와 브라우저가 민감한 정보를 주고 받을 때 해당 정보가 도난 당하는 것을 막아준다. (HTTP Message Body를 암호화한다.)

왜 HTTPS를 사용해야 할까?

http://velog.io/@newbiekim

http로 데이터를 전송할 경우, 네트워크로 원본 데이터가 전달된다. 따라서 해커가 중간에 데이터를 가로챈 다음, 해당 데이터를 보면 어떤 내용이 들어있는지 바로 알 수 있다.

https://velog.io/@newbiekim

HTTP와 달리 HTTPS로 전송할 경우 데이터를 암호화하여 전송한다. 그래서 해커가 중간에 데이터를 가로채더라도 데이터가 암호화되어 있기 때문에 어떤 내용인지 알기 어렵다.

SSL(Secure Sockets Layer)

Netscape Communications Corporation에서 웹 서버와 웹 브라우저 간의 보안을 위해 만든 프로토콜이다.
대칭키, 공개키-개인키(== 비대칭키) 기반으로 사용한다.

대칭키 방식
동일한 키로 암호화와 복호화를 수행한다. 누구든지 암호화에 이용된 키를 가지고 있다면 해당 데이터를 복호화할 수 있다.
암, 복호화가 쉽다는 장점이 있지만 키를 전달할 때 보안 상 문제가 생긴다는 단점을 갖고 있다.
공개키(비대칭키) 방식
서로 다른 키로 암호화와 복호화를 수행한다. 데이터 암호화 시 공개키를 사용하고 복호화 시에는 개인키를 사용한다. 공개키로 암호화한 데이터는 오직 개인키로만 복호화할 수 있다. 따라서 누구나 공개키를 가지고 있어도 상관없다. (→ 중간에 해커가 공개키를 가로채가도 문제 없다.)
공개키 방식은 대칭키에 비해 안전하지만 암호화 연산 시간이 더 많이 소요된다.

각 방식이 가진 장, 단점 때문에 SSL은 하나의 방식만 사용하지 않고 두 방식을 적절히 섞어 사용한다.