Steady and right

[jQuery] 탐색 선택자 (1) - 위치 탐색 선택자

MAENCO — Thu, 4 Nov 2021 21:56:20 +0900

탐색 선택자

탐색 선택자를 사용하면 기본 선택자로 선택한 요소 중 원하는 요소를 한번 더 탐색하여 좀 더 세밀하게 선택할 수 있다

위치 탐색 선택자

기본 선택자로 요소(태그)를 선택했을 경우 배열에 담기게 된다, 이때 배열의 인덱스(index)를 사용하면 특정 요소를 더 세밀하게 선택할 수 있는데 위치 탐색 선택자는 바로 이 인덱스를 활용하여 특정 요소를 선택하게 된다

구분	종류	사용법	설명
위치 탐색 선택자	first 선택자	$("선택 요소:first") $("선택 요소").first()	선택된 요소 중 첫번째 요소를 선택
	예시	$("#menu li:first") $("#menu li").first()
	last 선택자	$("선택 요소:last") $("선택 요소").last()	선택된 요소 중 마지막 요소를 선택
	예시	$("#menu li:last") $("#menu li").last()
	even 선택자	$("선택 요소:even")	선택한 요소 중 짝수 요소만 선택
	예시	$("#menu li:even")
	odd 선택자	$("선택 요소:odd")	선택한 요소 중 홀수 요소만 선택
	예시	$("#menu li:odd")
	eq(index) 탐색 선택자	$("선택 요소:eq(index)") $("선택 요소").eq(index)	선택한 요소 중 지정한 인덱스가 참조하는 요소만 선택
	예시	$("#menu li:eq(2)") $("#menu li").eq(2)
	it(index) 탐색 선택자	$("선택 요소:lt(index)")	선택한 요소 중 지정한 인덱스보다 작은 (less than) 요소만 선택
	예시	$("#menu li:lt(2)")
	gt(index) 탐색 선택자	$("선택 요소:gt(index)")	선택한 요소 중 지정한 인덱스보다 큰 (greater than) 요소만 선택
	예시	$("#menu li:gt(2)")
	first-of-type 선택자	$("선택 요소:first-of-type")	선택한 요소의 무리 중 첫번째 요소만 선택
	예시	$("li:first-of-type")
	last-of-type 선택자	$("선택 요소:last-of-type")	선택한 요소의 무리 중 마지막 요소만 선택
	예시	$("li:last-of-type")
	nth-child(n) 선택자	$("선택 요소:nth-child(n)")	선택한 요소의 무리 중 n번째 요소를 선택
	예시	$("#menu li:nth-child(2)")
	nth-child(Nn) 선택자	$("선택 요소:nth-child(Nn)")	선택한 요소의 무리 중 지정한 숫자(N)의 배수 요소를 선택
	예시	$("#menu li:nth-child(2n)")
	nth-last-of-type(n) 선택자	$("선택 요소:nth-last-of-type(n)")	선택한 요소의 무리 중 마지막에서 지정한 숫자의 요소를 선택
	예시	$("#menu li:nth-last-child(2)")
	only-child 선택자	$("선택 요소:only-child")	선택한 요소의 부모 요소에게 하나뿐인 자식이라면 선택
	예시	$("li:only-child")
	slice(index) 선택자	$("선택 요소").slice(start idx, end idx)	지정 구간 인덱스(start idx ~ end idx)의 요소를 선택,
	예시	$(".list").slice(1, 3)

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

참조 서적:

자바스크립트 + 제이쿼리 입문 : 정인용

[jQuery] 기본 선택자 (2) - 인접관계 선택자

MAENCO — Tue, 2 Nov 2021 21:01:33 +0900

인접 관계 선택자

인접 관계 선택자의 경우 직접 선택자로 요소(태그)를 먼저 선택하고 그다음 선택한 요소와 상관이 있는 (가까이에 있다던지 이전 혹은 그다음에 위치하고 있는) 요소를 선택할 때 사용한다.

구분	종류	사용법	설명
인접 관계 선택자	부모 요소 선택자	$("선택 요소").parent()	선택한 요소를 감싸고 있는 부모 요소를 선택
	예시	$("#menu").parent();
	상위 요소 선택자	1. $("선택 요소").parents() 2. $("선택 요소").parents("선택 요소")	1. 선택한 요소 기준으로 모든 상위 요소 선택 2. 선택한 요소 기준으로 상위 요소 중 선택한 요소만 선택
	예시	1. $(".example1").parents() 2. $(".example2").parents("span")
	가장 가까운 상위 요소 선택자	$("선택 요소").closest("선택 요소")	선택한 요소 기준으로 가장 가까운 상위 요소만 선택
	예시	$(".exampl1").closest("div")
	하위 요소 선택자	$("기준 요소 선택1 요소 선택2")	기준 요소로 선택한 하위 요소만 선택
	예시	$("#wrap h1") -> #wrap이 포함하는 모든 h1 요소를 선택
	자식 요소 선택자	1. $("선택 요소 > 자식 선택 요소") 2. $("선택 요소").children("자식 선택 요소") 3. $("선택 요소").children()	1&2. 선택한 요소 기준으로 지정한 자식 요소만 선택 3. 선택한 요소 기준으로 모즌 자식 요소를 선택
	예시	$("#wrap > h1") -> wrap 요소 안의 자식 요소 h1 선택 $("#wrap > section") -> wrap 요소 안의 section 요소안의 모든 요소 선택
	이전 요소 선택자	$("선택 요소").prev()	선택한 요소 기준으로 이전에 오는 형제 요소만 선택
	예시	$(".wrap").prev()
	다음 요소 선택자	1. $("선택 요소").next() 2. $("선택 요소1 + 선택 요소2")	1. 선택한 요소 기준으로 다음에 오는 형제 요소만 선택 2. 선택한 요소 기준으로 바로 다음에 오는 선택한 요소만 선택
	예시	1. $(".wrap").next().next() -> 체이닝 형식으로도 가능 2. $(".wrap + span") -> wrap 클래스 바로 다음에 오는 span 태그만 선택
	전체 이전 요소 선택자	$("선택 요소").prevAll()	선택 요소 기준으로 이전에 오는 모든 형제 요소를 선택
	예시	$(".wrap").prevAll()
	전체 다음 요소 선택자	$("선택 요소").nextAll()	선택 요소 기준으로 다음에 오는 모든 형제 요소를 선택
	예시	$(".wrap").nextAll()
	전체 형제 요소 선택자	$("선택 요소").siblings()	선택한 요소의 모든 형제 요소를 선택
	예시	$(".wrap").siblings()
	범위 제한 이전 요소 선택자	$("선택 요소").prevUntil ("범위 제한 선택 요소")	선택한 요소 기준으로 범위 제한 요소까지 전체 형(이전)요소 선택
	예시	$(".title6").prevUntil(".maintitle") -> title6 이전 형제 요소 중 maintitle 까지 선택
	범위 제한 다음 요소 선택자	$("선택 요소").nextUntil ("범위 제한 선택 요소")	선택한 요소 기준으로 범위 제한 요소까지 전체 동생(다음)요소 선택
	예시	$(".title3").nextUntil(".title7") -> title3 이후 형제 요소 중 title7 까지 선택

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

참조 서적:

자바스크립트 + 제이쿼리 입문 : 정인용

[jQuery] 기본 선택자 (1) - 직접 선택자

MAENCO — Thu, 28 Oct 2021 22:13:36 +0900

선택자

선택자는 HTML 요소를 선택해서 가져오는 역할을 한다. jQuery(제이쿼리)는 이 선택자를 통하여 HTML의 요소를 보다 쉽게 선택하여 동적인 CSS, 이벤트, 애니메이션 등을 적용할 수 있다. 매우 많은 선택자가 존재하며 본글에서는 기본선택자 중에 직접 선택자에 대하여 알아보고자 한다.

직접 선택자

구분	종류	사용법	설명
직접 선택자	전체 선택자	*$("")**	모든 요소를 선택
	예시	$("*").css("border", "1px solid black");
	아이디 선택자	$("#아이디명")	id 태그에 지정한 값을 선택
	예시	$("#menu").css("border", "1px solid black");
	클래스 선택자	$(".클래스명")	class 태그에 지정한 값을 선택
	예시	$(".category").css("border", "1px solid black");
	요소 선택자	$("요소명")	지정한 요소명과 일치하는 요소들을 선택
	예시	$("h1").css("border", "1px solid black");
	그룹 선택자	$("선택 1, 선택 2, ...")	선택 1, 선택 2 에 지정된 요소들을 한번에 선택
	예시	$("#menu, .category, h1").css("border", "1px solid black");
	종속 선택자	$("p.txt_1") $("p#txt_1")	<p> 태그 중 class 태그가 txt_1 또는 id 태그가 txt_1 인 요소를 선택
	예시	$("p.description").css("border", "1px solid black"); $("p#price").css("border", "1px solid black");

직접 선택자를 사용하여 내가 원하는 요소(태그)를 '직접' 선택하여 CSS 를 비롯한 이벤트, 애니메이션을 적용할 수 있다.

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

참조 서적:

자바스크립트 + 제이쿼리 입문 : 정인용

[jQuery] 제이쿼리(jQuery)란

MAENCO — Wed, 27 Oct 2021 00:11:52 +0900

제이쿼리(jQuery)의 탄생

이전에는 HTML의 Elements(요소)를 접근하는 것이 쉽지 않았다고 한다. 또한 웹브라우저마다 호환성이 떨어져 개발한 내용을 다른 브라우저에 적용하기가 어려웠다, 이에 제이쿼리가 요소의 접근을 물론 각 웹브라우저의 호환 더 나아가서는 애니메이션과 이벤트 등에도 편의 기능을 제공하며 자바스크립트에서 필수적인 존재로 자리 잡았다. (지금은 제이쿼리의 입지가 점점 더 좁아져 가는 상황이라고 한다.)

제이쿼리(jQuery)의 장점

제이쿼리가 왜 자바스크립트에서 많이 사용할 수 밖에 없었는지 장점을 통해 간단하게 알아보고자 한다.

1. HTML DOM의 접근성과 조작성

쉽게 말해 각 태그들에 접근하기가 용이하다, 제이쿼리의 선택자를 사용하면 클래스, 아이디 더 나아가서는 해당 요소의 위, 아래 그리고 형제 요소에 접근할 수 있다.

2. 웹브라우저의 호환성

제이쿼리 이전에는 각 웹브라우저의 호환성이 떨어져 개발자가 각 웹브라우저에 맞는 개발을 했어야 한다고 한다, 이에 제이쿼리는 거의 모든 웹브라우저에 적용할 수 있는 호환성을 갖춰 개발자는 제이쿼리 하나로 각 브라우저에 적용할 수 있었다고 한다.

3. 이벤트

자바스크립트의 특성상 다양한 이벤트에 응답하는데 (클릭, 입력과 같은 사용자와의 상호작용) 이때 사용자가 어떠한 행동을 할 때마다 맞춤으로 이벤트를 이용해 상호작용하여야 한다. 제이쿼리 이전에는 모든 웹브라우저가 동일한 방식으로 이벤트를 구현하지 않았는데 제이쿼리는 브라우저와 상관없이 동일한 이름으로 이벤트 기능을 제공함으로써 이벤트를 좀 더 편리하게 개발할 수 있게 되었다고 한다.

4. Ajax

비동기식 통신을 위해 Ajax를 사용할 때 이전에는 웹브라우저마다 그에 맞게 Ajax 코드를 작성했어야 한다고 한다. 제이쿼리의 경우 이벤트와 마찬가지로 이를 동일화 시켜 좀 더 편리하게 다양한 API를 개발할 수 있게 되었다고 한다.

핵심 정리

자바스크립트의 라이브러리인 제이쿼리가 나오기 이전에는 각 웹브라우저들의 호환성이 낮아 개발자가 브라우저마다 맞춤 개발을 했어야 했으나, 제이쿼리를 통해 HTML 요소에 대한 접근, 상호작용을 위한 이벤트, API 개발을 위한 Ajax 등을 거의 모든 웹브라우저에 한 번에 적용할 수 있다.

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

참조 링크:

https://opentutorials.org/course/53/45 https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html

https://code.tutsplus.com/tutorials/what-is-jquery--cms-26232

참조 서적:

자바스크립트 + 제이쿼리 입문 : 정인용

[WEB] 마크업 언어(Markup Language)

MAENCO — Wed, 13 Oct 2021 17:30:53 +0900

마크업 언어(Markup Language)란

마크업 언어는 태그 등을 이용하여 문서 혹은 데이터의 구조를 기록하는 언어로, 대부분 '기록'의 용도로 사용되기 때문에 프로그래밍 언어로 취급하지는 않는다고 한다.

조금 더 풀어서 살펴보기 위해 예를 들어보자면 클라이언트가 잡지를 읽는다고 가정해보자, 이때 1-10페이지 까지는 의류, 11-20 페이지 까지는 액세서리의 내용이 들어있다고 한다면, 이 페이지들은 하나하나 마크업으로 작성이 되어서 존재하는 것이다(인터넷에서는 웹페이지) 이것을 프로그래밍 언어로 각 페이지를 요청에 맞게 방문할 수 있게 하면 그것이 바로 서비스가 된다. 즉 클라이언트가 사용하는 웹서비스는 마크업언어를 기반으로 쌓아 올린 페이지들의 묶음인 것이다.

가장 대표적인 마크업의 사용 예는 아래의 예시처럼 단순하게 문장 혹은 글자 앞에 태그(여는 태그) 그리고 뒤에 태그(닫는 태그) 등을 사용하여 문서의 문서의 구조를 표현한다.

<p>TEST TEXT 1</p>
<span>TEST TEXT 2</span>

여는 태그와 닫는 태그 그리고 그 안의 내용을 합쳐서 Element라고 하는데 위의 예시에서 <p> 태그로 감싸져 있는 요소 같은 경우는 p element라고 한다.

마크업 언어도 여러 가지가 있는데 일반적으로 세 가지로 종류로 분류가 된다

∙ 표현적 마크업 (Presentational Markup)

전통적인 워드 처리 시스템이 사용하는 마크업, 즉 문서의 형태를 표현하기 위한 마크업이다. 대표적인 예는 HTML의 style태그를 생각하면 된다, 이 외에도 메모장이나 워드의 제목 앞에 몇 칸의 공백을 넣는 등의 행위도 표현적 마크업의 일종이라고 볼 수 있다.

∙ 절차적 마크업 (Procedural Markup)

프로그램이 문서를 처리하는 방법을 서술 마크업

∙ 기술적 마크업 (Descriptive Markup)

가장 많이 사용되는 마크업 언어의 종류이며 문서가 표현하는 내용을 기술한다, 대표적으로는 HTML과 마크업이 있다.

MarkDown Language

반대로 MarkDown 언어도 존재한다 간략하게 알아보자면, 흔히 사용하는 .md 확장자 파일이 바로 대표적인 마크다운 언어인데, 주로 SNS의 태그 기능에 사용한다고 한다.

핵심정리

웹브라우저가 해독할 수 있도록 문서를 구조화하는 언어가 바로 마크업 언어이다. 이렇게 만들어진 웹페이지가 모여 웹사이트가 되고 클라이언트에게 제공되는 서비스가 된다.

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

참조 링크:

https://ko.wikipedia.org/wiki/%EB%A7%88%ED%81%AC%EC%97%85_%EC%96%B8%EC%96%B4

https://blog.cordelia273.space/15

https://developerjio.tistory.com/entry/%EB%A7%88%ED%81%AC%EC%97%85-%EC%96%B8%EC%96%B4Markup-Language%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94

https://titus94.tistory.com/2

[JAVA] DTO와 VO의 차이

MAENCO — Fri, 1 Oct 2021 18:34:03 +0900

데이터를 위한 객체를 만들다 보면 항상 DTO와 VO를 혼용해서 쓰고 하는데, 어떤 것이 맞는 것인지 항상 헷갈렸다.

한번 정리해보면서 이 둘의 차이는 무엇이고 어떤 상황에서 쓰는 것이 가장 이상적인지 정리해보고자 한다.

DTO(Data Transfer Object)

순수하게 데이터를 담아 계층 간으로 전달하는 객체이다.

로직을 갖고 있지 않은 순수한 데이터 객체이며 메서드로는 getter/setter 만을 갖는다.

여기서 getter/setter 이외에 다른 로직이 필요 없는 이유를 좀 더 자세히 살펴보자면, 만약 DTO가 데이터 전달 만을 위한 객체라고 한다면 완전히 데이터 '전달' 용도로만 사용하기 때문에 getter/setter로직만이 필요하지 다른 로직이 필요하지 않은 것이다.

//getter와setter 메서드 만을 가진다
public class UserDTO {
    
    private String name;
    private String id;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
    
}

이를 통해 보내는 쪽에서는 setter를 이용하여 값을 담아 전달하고, 받는 쪽에서는 getter를 이용하여 값을 꺼내 쓰게 된다.

이때 setter의 경우 변조 가능성이 있기 때문에 아래와 같이 생성자로 값을 넣어주도록 하게 하면 전달하는 과정에서 변조가 불가능하다.

//생성자를 이용한 불변 객체
public class UserDTO {

    private String name;
    private String id;

    public UserDTO(String name, String id) {
        this.name = name;
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public String getId() {
        return id;
    }

}

VO(Value Object)

VO는 값 그 자체를 나태는 객체이다.

DTO와 반대로 로직을 포함할 수 있으며, VO의 경우 특정 값 자체를 표현하기 때문에 불변성의 보장을 위해 생성자를 사용하여야 한다.

VO는 서로 다른 이름을 갖는 VO 인스턴스라도 모든 속성 값이 같다면 두 인스턴스는 같은 객체인 것이 핵심이다.

예를 들어 모두 똑같은 자동차가 색깔만 다르다고 하더라도 이를 별개의 객체로 보는 것이 아니라 하나의 객체(자동차)로 보는것과 같다.

//생성자를 이용한 불변 객체
public class CarVO {

    private final String color;

    public CarVO(String color) {
        this.color = color;
    }
    
}

자동차의 색깔의 값을 가지고 있는 VO를 하나 만들어서 객체 두개를 아래와 같이 비교 테스트로 돌려보았다.

class CarVOTest {

    @Test
    void CarVOEqualTest() {
        final String color = "red";

        CarVO car1 = new CarVO(color);
        CarVO car2 = new CarVO(color);

        assertThat(car1).isEqualTo(car2);
        assertThat(car1).hasSameHashCodeAs(car2);

    }

}

당연하게도 객체의 주소값을 비교하기 때문에 값이 같은 것과는 상관없이 테스트에서 에러가 난다.

이러한 문제가 있기 때문에 값만을 비교하기 위해서 equals()와 hashCode()를 오버 라이딩(재정의) 해주어야 한다.

public class CarVO {

    private final String color;

    public CarVO(String color) {
        this.color = color;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        CarVO carVO = (CarVO) o;
        return Objects.equals(color, carVO.color);
    }

    @Override
    public int hashCode() {
        return Objects.hash(color);
    }
}

즉 VO는 값 그 자체를 나타내기 때문에 setter 같은 성격의 변조 가능성이 있는 메서드가 존재하면 안되며, 두 객체의 '필드 값이 같다면' 모두 같은 각체로 만드는 것이 핵심이다

DTO vs VO

DTO와 VO의 차이점을 정리해보면 아래와 같다.

여러 의견들을 찾아보며 느낀 것이지만 같이 혼용해서 사용하는 경우도 있고, 엄격하게 나눠 사용하는 경우도 있고 한 것 같다. 즉 합의하에 사용하면 되는 것이지 무엇을 어떻게 사용하는 것이 정답이다!라고 딱 잘라 말하기는 어렵다. 하지만 이름이 나뉘어 있고 해당 객체들이 하는 역할을 구분도 하니 대체적으로는 구분해서 사용하는 것이 좋지 않을까 하는 것이 개인적이 생각이다.

핵심정리

DTO는 계층간의 데이터를 전송하기 위한 객체로써, getter/setter를 사용하여 보내는 사람은 setter를 사용하여 값을 담고, 받는 사람은 getter를 사용하여 값을 꺼내 쓴다. 이때 값의 변조를 막고 싶다면 생성자로 불변 객체로 만들어 버리면 된다. 또한 DTO의 특성상 데이터 전달만은 목적으로 사용하기 때문에 getter/setter를 제외한 다른 로직이 필요가 없다.

VO의 경우 값 그 자체를 나타내는 객체로써, 핵심은 필드 값이 같다면 두 객체를 같은 객체로 본다는 것이다. 이때 당연하게도 주소값을 비교하는 경우의 문제점을 위해서 hashcode()와 equals()를 재정의하여 필드 값이 같다면 같은 객체로 인식될 수 있도록 해주어야 한다.

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

참조 링크:

https://www.youtube.com/watch?v=z5fUkck_RZM&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9CTech

https://velog.io/@taehee-kim-dev/DTO-vs-VO

https://tecoble.techcourse.co.kr/post/2020-06-11-value-object/

[Git] Git의 이해

MAENCO — Sat, 25 Sep 2021 20:35:44 +0900

Git이란

개발을 할 때 꼭 필요한 것 중에 하나가 바로 버전을 관리하는 시스템인데, Git이 바로 이 작업을 도와주는 버전 관리 시스템 중 하나이다, 마치 게임의 세이브 파일처럼 코드의 작업 중간중간에 세이브 포인트를 만들어 이 포인트들로 자유롭게 옮겨 갈 수 있다 (단순히 ctrl+z를 하는 것과는 다르다는 점)

즉 이러한 세이브 포인트를 하나 하나 꽂아나가며 이를 통해 이전의 포인트로 돌아갈 수도 있고, 돌아갔던 이력을 다시 되돌릴 수도 있다.

• SVN vs Git

이전에는 SVN이라는 버전관리 시스템을 사용하기도 했으나 현재는 대부분 Git을 사용하는 추세라고 한다, SVN의 경우 중앙 서버에 소스코드와 히스토리를 저장하여야 하기 때문에 서버에 장애가 발생하게 되면 접근이 불가능하고 한 곳에서 관리되다 보니 리스크 또한 비교적 컸다, Git의 경우에는 로컬 저장소에 소스코드를 분산해서 저장하기 때문에 이러한 리스크의 문제점을 해결할 수 있고, 또한 서버를 통하지 않아 SVN과 비교해서 훨씬 빠르다는 장점이 있다

CLI vs GUI

Git을 사용하여 버전을 관리하는데는 두 가지 방법이 있다, Command Line Interface(CLI)와 Graphic User Interface(GUI)로 구분되는데, 이 둘 중 맞는 방법은 없으며 상황 혹은 기호에 따라 사용하면 된다.

•CLI

Terminal(윈도우에서는 Git Bash)을 이용하여 직접 명령어를 입력하여 Git 작업을 실행하는 방법이다

•GUI

프로그램을 통하여 버튼 등을 클릭하여 보다 직관적으로 Git 작업을 실행하는 방법이다

Git Cloud

만약 다수의 사람들이 '협업' 으로 코드를 개발한다면, 로컬 저장소에 분산되어 저장한다고 하더라도 결과물을 만들기 위해서는 한 곳에서 각자의 결과물들을 합쳐야 할 것이다, 이런 작업을 위한 서버를 지원하는 GitHub, Bitbuket, Gitlab 등등이 있다. 이때 주의해야 할 점은 나의 경우 GitHub를 주로 사용하는데 처음에는 Git과 GitHub가 비슷한 개념인 줄 알았다, 하지만 GitHub와 같은 Git Cloud의 경우 서버를 제공하는 것일 뿐 Git과는 다른 개념이라는 것

이러한 Git Cloud를 이용하여 로컬저장소에 분산되어 저장되어 있던 결과물들을 서버에도 저장할 수도 있고, 이를 합칠 수도 있다. 더 나아가서는 오픈소스 같은 프로젝트를 통째로 가져와 사용할 수도 있다

핵심정리

게임 진행 중에 세이브 포인트를 저장하는 것처럼, 개발을 하는 작업 중에도 중간 중간에 되돌아갈 수 있는 세이브 포인트를 만드는 작업이 바로 버전 관리의 핵심이다, 이러한 작업의 결과물들을 Git Cloud에 저장하여 공유할 수도, 결과물을 합칠 수도 있다

Git은 직접 명령어를 입력하여 실행하는 CLI와, 프로그램을 통하여 버튼 등을 클릭하는 GUI의 방식으로 나뉜다

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

[Spring MVC] MultipartFile (File Upload)

MAENCO — Thu, 23 Sep 2021 11:39:21 +0900

(참고: Spring Boot와 Thymeleaf를 기준으로 작성된 글입니다)

HTML Form 전송 방식

HTML Form을 통한 파일 업로드를 이해하기 위해서는 두 가지 방식의 차이를 알아야 한다

• application/x-www-form-urlencoded

<form action="/save" method="post">
    <input type="text" name="usernmae"/> //kim
    <input type="text" name="age"/> //20
    <button type="submit">전송</button>
</form>

application/x-www-form-urlencoded 방식은 HTML 폼 데이터를 서버로 전송하는 가장 기본적인 방법이다, Form 태그에 별도의 enctype옵션이 없다면 웹 브라우저는 요청 HTTP의 헤더에 다음과 같이 추가하여, 폼에 입력한 항목을 HTTP 바디와 함께 전송한다

POST/save HTTP/1.1
Host:localhost:8080
Content-Type:application/x-www-form-urlencoded

username=kim&age=20

하지만 파일을 업로드하려면 문자가 아닌 바이너리 데이터를 전송해야 하고, 파일뿐만 아니라 보통 폼을 전송할 때 파일과 함께 입력한 항목들을 같이 전송해야 한다는 문제점이 있다

• multipart/form-data

파일과 함께 항목을 같이 전송하기 위하여 HTTP는 multipart/form-data라는 전송 방식을 제공한다, multipart라는 이름처럼 다른 종류의 여러 파일과 폼의 내용을 '함께' 전송할 수 있다

<form action="/save" method="post" enctype="multipart/form-data">
    <input type="text" name="usernmae"/> //kim
    <input type="text" name="age"/> //20
    <input type="file" name="file"/> //example.png
    <button type="submit">전송</button>
</form>

위의 예시와 같이 enctype을 multipart/form-data로 지정하게 되면 여러 개의 파트로 나누어 각각의 전송 항목을 구분한다

POST/save HTTP/1.1
Host:localhost:8080
Content-Type:multipart/form-data,boundary=------XXX

-------XXX
Content-Disposition: form-data; name="username"

kim
-------XXX
Content-Disposition: form-data; name="age"

20
-------XXX
Content-Disposition: form-dta; name="file"; filename="example.png"
Content-Type: image/png

(바이너리 코드....)
-------XXX--

이렇게 multipart/form-data는 각각의 항목을 구분해서, 한 번에 전송하는 원리이다

MultipartFile

위에서 Form 통해 전송해온 파일들을 편리하게 받을 수 있게 스프링에서는 MultipartFille이라는 인터페이스를 지원한다

@Controller
public class FileController {
    
    @PostMapping("/save")
    public String saveFile(@RequestParam MultipartFile file) {
    }
    
}

위의 예시처럼 @RequestParam을 업로드하는 HTML Form의 name에 맞추어 적용하면 되며, @ModelAttribute에서도 동일하게 사용할 수 있다, MultipartFile인터페이스의 주요 메서드는 아래와 같다

• file.getOriginalFileName() : 업로드 파일 명

• file.transferTo(...) : 파일 저장

UUID Filename + ExtendName

보통 클라이언트가 보내는 이미지 파일은 서버에서 UUID 등의 구분자를 부여하여 관리하게 된다, 그 이유는 만약 클라이언트 A가 올린 파일과 클라이언트 B가 올린 파일의 내용은 다르지만 이름이 같은 경우에 덮어쓰기가 되기 때문이다, 또한 확장자 파일명을 따로 붙여줘 더욱 편리하게 파일들을 관리할 수 있도록 해주는 것이 좋다고 한다

//메서드를 따로 만들어 공용으로 사용

private String extractExt(String originalFilename) {
    int pos = originalFilename.lastIndexOf(".");
    return originalFilename.substring(pos + 1);
}

private String createStoreFileName(String originalFilename) {
    String ext = extractExt(originalFilename);
    String uuid = UUID.randomUUID().toString();
    return uuid + "." + ext;
}

핵심정리

클라이언트가 Form 통하여 파일을 보내는 경우, 보통 폼에 입력한 항목들을 같이 전송하기 때문에 MultipartForm을 사용하여 보내게 된다, 말 그대로 여러 파트로 구분하여 보내어지는데 스프링에서는 서버 측에서 편리하게 받을 수 있도록 MultipartFile이라는 인터페이스를 지원한다

서버에서 받게 된 파일은 UUID 등의 구분자를 통하여 중복되어 덮어 써지는 일을 방지하고 확장자명까지 추출해내어 추후에도 파일을 편리하게 관리하는 것이 좋다

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

참조 링크:

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2/dashboard

[Spring MVC] TypeConverter & Formatter

MAENCO — Tue, 21 Sep 2021 22:59:34 +0900

(참고: Spring Boot, Thymeleaf, Gradle을 기준으로 작성된 글입니다.)

웹 애플리케이션의 경우 클라이언트가 보내는 데이터와 서버에서 다시 반환하는 데이터 간의 타입이 불일치하는 경우가 빈번하게 발생한다, 예를 들어 String으로 보낸 데이터를(HTTP 요청 파라미터의 경우 모두 문자 타입으로 처리됨) int타입으로 변환해야 한다던지, 보낸 데이터를 개발자가 지정한 객체에 담아서 받는 상황이 대표적인 경우다

Converter Interface

이러한 변환 과정을 편리하게 사용할 수 있도록 스프링은 기본적으로 컨버터를 적용시키지만 개발자가 직접 원하는 타입으로 변환을 위하여 컨버터 인터페이스의 구현체를 만들 수도 있다

package org.springframework.core.convert.converter;

public interface Converter<S, T> {
    T convert(S source);
}

위의 컨버터 인터페이스는 스프링에서 제공하는 확장 가능한 컨버터 인터페이스다, 즉 이 컨버터 인터페이스를 구현해서 등록하게 되면 추가적인 타입 변환을 할 수 있는 것이다 (과거에는 PropertyEditor를 이용해서 타입을 변환하였으나, 동시성 문제 때문에 현재는 Converter를 대부분 사용하고 있다고 한다)

• Integer -> String

컨버터 인터페이스를 구현하기 위한 방법은 굉장히 단순하다 S -> T 로 변환되는 개념이기 때문에 아래와 같이 작성하게 되면 숫자를 문자로 변환하는 타입 컨버터가 된다(단순히 동작 원리의 이해를 위한 것이지, 아래와 같이 단순하게 숫자 -> 문자의 경우 기본 컨버터가 지원한다는 점 참고)

public class IntegerToStringConverter implements Converter<Integer, String> {
    @Override
    public String convert(Integer source) {
        log.info("convert source={}", source);
        return String.valueOf(source);
    }
}

• String -> Object

단순히 숫자를 문자로 변환하는 것을 넘어서 문자를 내가 원하는 객체의 형식으로 컨버팅 할 수도 있다

@Getter
@EqualsAndHashCode
public class IpPort {

    private String ip;
    private int port;
    
    public IpPort(String ip, int port) {
        this.ip = ip;
        this.port = port;
    }
}

@Slf4j
public class StringToIpPortConverter implements Converter<String, IpPort> {

    @Override
    public IpPort convert(String source) {
        log.info("convert source={}", source);
        String[] split = source.split(":");
        String ip = split[0];
        int port = Integer.parseInt(split[1]);
        
        return new IpPort(ip, port);
    }
    
}

위와 같이 작성할 경우 "127.0.0.1:8080"이라는 문자가 들어왔을 때 IpPort객체의 ip에는 : 이전의 ip가, port에는 : 이후의 포트번호가 들어가게 된다

ConversionService

허나 이렇게 일일이 타입 컨버터를 불러들여 적용하기에는 매우 불편하다, 그래서 스프링은 개별 컨버터를 모아 두고 그것들을 묶어서 편리하게 사용할 수 있는 기능을 제공하는데 바로 ConversionService이다

//실제 ConversionService 코드
public interface ConversionService {
    boolean canConvert(@Nullable Class<?> sourceType, Class<?> targetType);
    boolean canConvert(@Nullable TypeDescriptor sourceType, TypeDescriptor targetType);
    <T> T convert(@Nullable Object source, Class<T> targetType);
    Object convert(@Nullable Object source, @Nullable TypeDescriptor sourceType,TypeDescriptor targetType);
}

ConversionService 인터페이스의 경우 단순히 컨버팅의 가능여부와 컨버팅 기능을 제공한다

@Configuration
public class WebConfig implements WebMvcConfigurer {
  
    @Override
    public void addFormatters(FormatterRegistry registry) {
         registry.addConverter(new IntegerToStringConverter());
         registry.addConverter(new StringToIpPortConverter());
    }
    
}

사용하기 위해서는 Configuration 클래스를 하나 만들어 위와 같이 만든 컨버터를 직접 등록하면 스프링이 기본적으로 제공하는 컨버터보다 높은 우선순위를 가지고 있기 때문에 해당 컨버터들이 작동하게 된다

View Template

뷰 템플릿에 렌더링 하는 과정에 컨버터를 사용할 수도 있다, 타임리프의 경우 ${...}의 변수 표현식을 사용하여 내용을 렌더링하는데 컨버팅 서비스를 적용하기 위해서는 ${{...}}로 괄호를 하나 더 붙여 사용하게 된다

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body> 

     <span th:text="${ipPort}"></span>
     <span th:text="${{ipPort}}"></span>
     
</body>
</html>

변수 표현식 : ${ ... }

컨버전 서비스 적용 : ${{ ... }}

th:field를 사용한다면 괄호의 개수와 상관없이 컨버전 서비스가 적용된다

Formatter

컨버터의 경우 입력과 출력 타입에 제한이 없는 범용적인 타입 변환 기능을 제공한다, 하지만 대부분의 경우 문자를 다른 타입으로 변환하거나 다른 타입을 문자로 변환하는 상황이 대부분이다

ex. 1000(숫자) -> "1,000"(문자)

ex. "2021-01-01 01:01:11"(문자) -> 2021-01-01 01:01:11(날짜)

이럴 때 사용하는 것이 바로 포맷터인데, 포맷터 또한 컨버터의 개념 안에 속한다. 즉 특정한 포맷에 맞추어 문자로 출력하거나 그 반대의 역할을 하는 기능에 특화되어 있는 기능으로 특별한 버전의 컨버터라고 이해하면 된다

• Converter : 범용적인 사용 (객체 -> 객체)

• Fomatter : 문자에 특화 (객체 -> 문자, 문자 -> 객체) + 현지화(Locale)

//Fomatter 인터페이스 실제 코드
public interface Printer<T> {
    String print(T object, Locale locale);
}

public interface Parser<T> {
    T parse(String text, Locale locale) throws ParseException;
}

public interface Formatter<T> extends Printer<T>, Parser<T> {
}

여기서 주목해야 할 점이 현지화라는 정보를 같이 넣을 수 있다는 것인데, 예를 들어 숫자를 표기할 때 1,000와 같은 표기법 혹은 날짜의 표기법이 지역마다 다를 수 있다 이를 Locale의 정보를 입력하여 매우 간편하게 특정 포맷으로 변환하는 것은 물론 1000(숫자) -> "1,000"(문자)와 같은 변환은 사실 생각보다 구현하는 것이 복잡하고 또 번거로운 작업이 수반되기 때문에 이러한 작업을 최소화할 수 있다

@Slf4j
public class MyNumberFormatter implements Formatter<Number> {

     //"1,000" -> 1000
     @Override
     public Number parse(String text, Locale locale) throws ParseException {
          log.info("text={}, locale={}", text, locale);
          NumberFormat format = NumberFormat.getInstance(locale);
          return format.parse(text);
     }
     
     //1000 -> "1,000"     
     @Override
     public String print(Number object, Locale locale) {
          log.info("object={}, locale={}", object, locale);
          return NumberFormat.getInstance(locale).format(object);
     }
     
}

포맷터의 parse는 문자를 숫자로 변환하고, print의 경우 객체를 문자로 변환한다

포맷터 또한 Configuration 클래스에 등록하여 사용하면 된다

@Configuration
public class WebConfig implements WebMvcConfigurer {

     @Override
     public void addFormatters(FormatterRegistry registry) {
          registry.addFormatter(new MyNumberFormatter());
     }
     
}

@Formatter

스프링은 자바에서 기본으로 제공하는 타입들에 대해 수 많은 포맷터를 기본으로 제공한다, 하지만 포맷터의 경우 형식이 지정되어 있기 때문에 객체의 각 필드마다 다른 형식의 포맷을 지정하기는 어렵다, 이를 해결하기 위해서 스프링은 애노테이션 기반의 포맷터를 제공한다, 본글에서는 기본으로 제공하는 @NumberFormat과 @DateTimeFormat을 살펴보고자 한다

public class Form {
     
     @NumberFormat(pattern = "###,###")
     private Integer number;
     
     @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")
     private LocalDateTime localDateTime;
     
}

이렇게 각각의 필드에 애노테이션을 달고 패턴을 입력해주게 되면 해당 포맷으로 변환된다

JSON과 컨버팅

메시지 컨버터(HttpMessageConverter)의 경우 컨버전 서비스가 적용되지 않는다, 특히 객체를 JSON으로 변환할 때 메시지 컨버터를 사용하는데 메시지의 컨버터의 역할을 생각해보자면 HTTP 메시지 바디의 내용을 객체로 변환하거나 그 반대의 경우를 수행하는 게 제 기능이다. 예를 들어 JSON으로 변환하는 경우 메시지 컨버터는 내부에서 Jackson과 같은 라이브러리를 사용한다 즉 이 과정에서 변환하는 과정은 해당 라이브러리가 담당하는 것이지 컨버전 서비스와는 아무런 관계가 없다는 것이다, 그러하여 만약 이와 같은 작업에 포맷터를 적용하고 싶다면 해당 라이브러리가 제공하는 설정을 통해서 포맷을 설정하여야 한다

핵심정리

편리하게 타입을 변환할 수 있도록 스프링은 타입 컨버터라는 기능을 제공한다. 이를 통하여 숫자에서 문자로, 문자에서 숫자로 편리하게 타입을 변환할 수 있으며 직접 컨버터 인터페이스의 구현체를 구현하여 컨버팅 하고자 하는 양식을 만들 수도 있다, 또한 컨버전 서비스라는 기능을 이용하여 컨버터를 한 번에 묶어 사용하고 관리할 수 있다

포맷터의 경우 특별한 컨버터라고 이해하면 쉬운데, 예를 들어 1000이라는 숫자를 "1,000"와 같이 특정한 포맷으로 바꾸고 싶을 때 편리하게 사용할 수 있다, 여기에 Locale이라는 데이터를 더하여 해당 지역에서 사용하는 포맷을 적용시킬 수 있다. 이러한 포맷터의 경우 기본적으로 지정한 형식에 따르기 때문에 각각의 필드에 다른 형식을 적용하기 어려운데 이를 해결하기 위하여 스프링은 애노테이션으로 된 포맷터를 제공하여 각각의 필드에 패턴을 지정하여 해당 포맷으로의 변환을 가능케 해준다

JSON의 경우 메시지 컨버터가 작동하여 내부에서 해당 라이브러리를 사용하기 때문에 컨버전 서비스와 전혀 관계가 없으며, 이러한 경우에도 포맷을 설정하고 싶다면 해당 라이브러리가 제공하는 설정을 따라 포맷을 적용하여야 한다

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

참조 링크:

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2/dashboard

[Spring MVC] API Error (API 오류 처리)

MAENCO — Fri, 17 Sep 2021 17:21:03 +0900

(참고: Spring Boot를 기준으로 작성된 글입니다)

HTML 페이지 vs API 오류

단순히 HTML 웹페이지를 반환하였던 오류의 경우에는 스프링 부트가 제공하는 BasicErrorController로 충분하였다, 404 혹은 4xx의 오류코드만 확인하여 해당 HTML을 클라이언트(사용자)에게 반환해주었으면 그만이니 말이다

하지만 API의 경우 이것보다 훨씬 세밀하고 복잡한 상황을 마주한다, API 같은 경우는 안드로이드와 아이폰 혹은 기업과 기업 간의 다양한 객체들이 소통하며 각기 다른 조건과 요구사항을 만족하여 오류처리를 하여야 하기 때문이다

예를 들어 회원관리에서만 발생하는 오류와, 상품관리에서만 발생하는 오류를 각각 묶어서 처리하고 싶다면 기존의 단순히 HTML을 반환하는 오류처리와는 다르게 각각의 컨트롤러 혹은 예외마다 서로 다른 응답 결과를 출력해야 하는 상황이 발생하는 것이다

HandlerExceptionResolver의 기본 흐름과 목적(Exception Resolver)

이렇게 다양한 결과물을 출력하기 위하여 스프링은 HandlerExceptionResolver라는 것을 제공한다

그렇다면 Exception Resolver가 어떻게 작동하는지 흐름도를 살펴보자 (인터셉터가 적용되어 있는것 주의)

1. preHandle을 호출한다

2. 핸들러(컨트롤러)를 호출한다

3. 예외가 발생한다

4. postHandle은 호출되지 않고 afterCompletion이 되어진다

1. preHandle을 호출한다

2. 핸들러(컨트롤러)를 호출한다

3. 예외가 발생한다

4. postHandle을 여전히 호출되지 않고 ExceptionResolver에 예외를 처리할 수 있는지 확인한다

5. afterCompletion을 호출한다

6. 만약 ExceptionResolver에서 처리할 수 있다면 ModelAndView를 반환한다

얼핏 보면 큰 차이가 없을 것 같지만, 막상 활용을 하게 된다면 큰 차이가 있다. 특히 API의 오류인 경우 굉장히 다양한 형식으로 오류 메시지를 반환하거나 코드를 반환하여야 하는데, 기존의(ExceptionResolver 적용 전) 경우 결국 예외가 터지게 되면 WAS로 흘러들어 가 에러 페이지를 호출하는 과정을 겪는 반면에, ExceptionResolver를 적용하게 되면 이 예외를 잡아 해결하고 정상적인 흐름처럼 클라이언트에게 반환할 수 있다

즉 ExceptionResolver를 적용하는 핵심은 try ~ catch를 하듯 Exception(예외)이 터지게 되면 이를 해결하여(Resolver) 정상적인 흐름처럼 변경하는 것이 주된 목적이다

ExceptionResolver가 반환하는 값에 따른 동작은 아래와 같다

1. 빈(Empty) ModelAndView : 빈 모델 뷰를 반환하면 뷰를 렌더링 하지 않고 정상 흐름처럼 서블릿에게 리턴된다

2. ModelAndView 지정 : 모델 뷰에 model, view 등의 정보를 지정해서 반환하게 되면 뷰를 렌더링 한다

3. null : null을 반환하게 되면, 다음 ExceptionResolver를 찾아서 실행한다, 만약 없다면 예외 처리가 안되고 기존처럼 예외를 서블릿 밖으로 즉 WAS로 던지게 된다

ExceptionResolver의 종류와 우선순위

ExceptionResolver를 찾지 못하면 다음 Resolver를 검색하는데 이 과정에서 우선순위가 존재하며 아래와 같다

1. ExceptionHandlerExceptionResolver (중요)

@ExceptionResolver를 처리한다 API 예외 처리의 경우 대부분 이 기능으로 해결한다, 위에서 설명한 ExceptionResolver의 경우 모델 뷰를 반환하는데 이는 API 응답에 필요가 없을뿐더러, API의 JSON형식 응답을 위해서 매우 번거로운 작업이 필요하다. 이런 모든 문제를 해결하는 것이 바로 @ExceptionResolver이다

//예외 발생 시 API응답에 사용할 객체
@Data
@AllArgsConstructor
public class ErrorResult {
    private String code;
    private String message;
}

@ExceptionHandler(IllegalArgumentException.class)
public ErrorResult illegalExHandle(IllegalArgumentException e) {
    return new ErrorResult("BAD", e.getMessage());
  }

위의 예시처럼 아주 간단하게 애노테이션만으로 예외가 발생하였을 때 해당 예외를 캐치하여 API 응답에 사용한 객체를 반환한다

{
    "code": "BAD",
    "message": (생략)
}

만약 @ExceptionHandler의 예외를 지정하지 않으면 해당 메서드 파라미터 예외를 사용하게 되는데 이럴 경우 ResponseEntity를 사용하여 응답 코드를 동적으로 변경할 수 있다 (아래에서 살펴볼 ResponseStatus는 동적 변경 불가능)

//사용자가 직접 만든 익셉션
@Slf4j
public class ExampleExeption extends RuntimeException{

    public ExampleExeption() {
        super();
    }

    public ExampleExeption(String message) {
        super(message);
    }

    public ExampleExeption(String message, Throwable cause) {
        super(message, cause);
    }

    public ExampleExeption(Throwable cause) {
        super(cause);
    }

    protected ExampleExeption(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace) {
        super(message, cause, enableSuppression, writableStackTrace);
    }
}

@ExceptionHandler
public ResponseEntity<ErrorResult> exampleExHandle(ExampleException e) {}

이 외에도 다양한 반환 값을 사용할 수 있다

• @ReponseBody

• HttpEntity<B>, ResponseEntity<B>

• String

• View

• Map, Model

• @ModelAttribute

(더욱 자세한 내용은 공식문서 참고 :

https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann- exceptionhandler-args)

• @ExceptionHnalder의 우선순위

@ExceptionHandler 또한 예외처리에서 우선순위가 존재한다

@ExceptionHandler(부모예외.class) 
public String 부모예외처리()(부모예외 e) {}

@ExceptionHandler(자식예외.class) 
public String 자식예외처리()(자식예외 e) {}

부모 클래스와 자식 클래스가 같이 있다고 한다면 부모 클래스의 예외 처리 시 자식 클래스 또한 같이 예외 처리가 된다, 이때 스프링에서 항상 디테일한 것이 우선순위를 가지듯이 자식 클래스와 같은 더 디테일한 예외조건이 있다면 해당 조건이 적용된다, 이를 활용한다면 범용적인 예외에서 디테일한 예외로 범위를 지정할 수 있는 즉 다양한 예외를 한 번에 처리할 수 있다

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

2. ReponseStatusExceptionResolver

HTTP 상태 코드를 지정할 수 있다 (ex. @ResponseStatus(value = HttpStatus.NOT_FOUND)

이를 사용하는 이유는 라이브러리를 활용하는 경우 개발자가 직접 예외 코드를 변경할 수 없기 때문에 이를 적용할 때 사용하게 된다, 예시와 함께 살펴보자

@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "잘못된 요청 오류") 
public class BadRequestException extends RuntimeException {
}

//실제 ResponseStatusExceptionResolver 코드
protected ModelAndView applyStatusAndReason(int statusCode, @Nullable String reason, HttpServletResponse response)
    throws IOException {

    if (!StringUtils.hasLength(reason)) {
        response.sendError(statusCode);
    } else {
        String resolvedReason = (this.messageSource != null ?
        this.messageSource.getMessage(reason, null, reason, LocaleContextHolder.getLocale()) :reason);
        response.sendError(statusCode, resolvedReason);
    }
    return new ModelAndView();
}

ResponseStatusExceptionResolver가 작동하는 코드를 확인해보면 결국 서블릿의 response.sendError(statusCode, resolvedReson)을 사용하기 때문에 sendError(400)을 호출하게 되면 WAS에서 오류 페이지를 요청하게 된다

@GetMapping("/api/responsereoslver")
public String responseStatus() {
    throw new BadRequestException();
}

이를 위와 같이 API 오류에 반환하게 된다면 아래와 같이 출력된다

{
    "status": 400,     
    "error": "Bad Request",
    "exception": "hello.exception.exception.BadRequestException", 
    "message": "잘못된 요청 오류",\
    "path": "/api/responsereoslver"
}

여기서 반환되는 reason의 경우 굉장히 재밌는 기능을 제공하는데, 바로 스프링 메시지를 활용할 수 있다는 것이다, 예를 들어 반환되는 reason에 error.badRequest와 같이 작성한 후 스프링 메시지 소스(messages.properties)에 등록하면 해당 내용이 출력된다

마지막으로 @ExceptionHandler와 같이 사용할 수도 있다

@ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(IllegalArgumentException.class)
public ErrorResult illegalExHandle(IllegalArgumentException e) {
    return new ErrorResult("BAD", e.getMessage());
}

3. DefaultHandlerExceptionResolver

마지막 우선순위로 호출되는 DefaultHandlerExceptionResolver는 스프링 내부의 기본 예외 처리를 한다, 대표적으로 파라미터 바인딩 시점에 타입이 맞지 않은 경우 TypeMismatchException이 발생하는데, 이런 경우 예외가 발생하였기 때문에 그냥 두게 되면 서블릿 컨테이너까지 올라가게 되고 결과적으로는 서버 내부에서 발생한 오류 즉 500 에러코드가 발생한다, 하지만 타입 미스매치 같은 오류는 클라이언트가 잘못 보낸 것이지 서버상의 오류는 아니다

이때 DefaultHandlerExceptionResolver가 각 상황에 맞는 응답 코드를 리턴해준다

요청에 맞는 컨트롤러(핸들러)를 못 찾는 경우 -> 404 Not Found

컨트롤러 실행 중 예외가 발생하는 경우 -> 500 Internal Server Error

컨트롤러의 파라미터 타입 미스매치 경우 -> 400 BadRequest

@GetMapping("/api/defaulthandler")
public String defaultException(@RequestParam Integer data) {
    return "ok"; (정상적인 경우 ok가 반환)
}

만약 위와 같은 컨트롤러에 문자열인 데이터를 보냈다고 한다면 기존처럼 500 에러코드를 반환하는 것이 아닌 아래와 같이 400 에러코드를 반환하게 된다

{
    "status": 400,
    "error": "Bad Request",
    "exception": "org.springframework.web.method.annotation.MethodArgumentTypeMismatchException",
    "message": (생략)
    "path": "/api/defaulthandler"
}

ExceptionResolver 활용 후의 흐름 정리

위에서 살펴본 다양한 ExceptionResolver가 적용되고 나서의 흐름을 한번 더 정리해보고자 한다

//예외 예시
@ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(IllegalArgumentException.class)
public ErrorResult illegalExHandle(IllegalArgumentException e) {
    return new ErrorResult("BAD", e.getMessage());
}

3번까지는 기존과 동일한 흐름 (예외 발생은 IllegalArgumentException)

4.1. 예외가 발생하였기 때문에 ExceptionResolver가 작동한다, 이때 가장 우선순위가 높은 @ExceptionHandler에서 가 작동하고 해당 컨트롤러에 발생한 예외를 처리할 수 있는 @ExceptionHanlder가 존재하는지 확인한다

4.2. ResponseStatus에 지정된 응답 코드를 반환한다

5. afterCompletion 호출

6. 예외처리가 되었으므로 API 응답

@ControllerAdvice

API의 경우 각 컨트롤러마다 다른 예외를 응답해야 하는 상황이 필요하다 이때 @ControllerAdvice를 활용하여 각 컨트롤러에 적용시킬 예외처리를 나누어 관리할 수 있다 (만약 @ControllerAdvice를 지정하지 않으면 모든 컨트롤러에 적용된다 (글로벌 적용))

// Target all Controllers annotated with @RestController
@ControllerAdvice(annotations = RestController.class)
public class ExampleAdvice1 {}

// Target all Controllers within specific packages
@ControllerAdvice("org.example.controllers")
public class ExampleAdvice2 {}

// Target all Controllers assignable to specific classes
@ControllerAdvice(assignableTypes = {ControllerInterface.class,AbstractController.class})
public class ExampleAdvice3 {}

위의 예시처럼 특정 애노테이션이 있는 컨트롤러를 지정할 수도 있고, 특정 패키지를 지정할 수도 있다. 패키지 지정 같은 경우 해당 패키지와 그에 속한 하위 패키지가 대상이 된다 마지막으로 클래스를 지정할 수도 있다

핵심정리

API 오류 처리 같은 경우, 단순한 웹페이지를 반환하는 것과는 달리 다양한 형식을 사용하거나 각각의 컨트롤러에 각기 다른 예외를 적용시켜야 하는 상황이 빈번하다, 또한 단순히 데이터를 반환하는데 WAS에서 다시 요청을 할 필요도 없다

이러한 문제점을 해결하기 위해 ExceptionResolver(HandlerExceptionResolver)를 사용하여, 예외가 발생하였을 때 Resolver에서 예외를 처리할 수 있는지 확인하고 예외 처리가 된다면 정상적인 흐름처럼 클라이언트에게 응답하게 된다

ExceptionResolver는 총 3가지가 있지만 대부분 API 응답에 사용하는 Resolver는 ExceptionHandlerExceptionResolver로 애노테이션화 되어 있어 매우 간편하게 사용할 수 있다, @ExceptionHandler를 사용하여 적용시킬 예외를 지정하고, 지정하지 않는다면 파라미터와 반환 값을 동적으로 만들어 반환할 수도 있다

마지막으로 @ControllerAdvice를 사용하게 되면 예외를 적용시키고자 하는 애노테이션, 패키지, 클래스까지 지정하여 각각 다른 예외 조건들을 설정할 수 있다

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

참조 링크:

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2/dashboard

https://jaehun2841.github.io/2018/08/30/2018-08-25-spring-mvc-handle-exception/#responsestatusexceptionresolver