Merge pull request #39 from SSUMC-6th/seungsu/#8

[승수] Chapter 8. API 응답 통일 & 에러 핸들러

docs/chapter8/ch_08keyword

@@ -0,0 +1,66 @@
+- Spring의 의존성 주입
+
+    ***스프링 컨테이너에서 객체 Bean을 먼저 생성해두고 생성한 객체를 지정한 객체에 주입하는 방식을 의존성 주입 이라고 함***
+
+    객체 자체가 코드 상에서 객체 생성에 관여하지 않아도 되기때문에 객체 사이의 의존도를 낮출수 있음. 
+
+    스프링 컨테이너에서 객체의 생명주기를 관리하며 객체의 의존관계 또한 관리해주기에 유연하고 확장성이 뛰어난 코드 작성이 가능해짐 
+
+- IoC 컨테이너
+
+    제어의 역전이란 Inversion of Control의 약자로, 프로그램의 제어를 다른 대상이 맡는 것을 말하며 이 때 스프링에서 개발자가 직접적으로 객체의 생성 및 관리를 담당하는 대신,  의존 관계 주입 등의 역할을 하는 컨테이너를 IoC컨테이너라고 한다.
+
+    주로 서버 내에 포함되어 배포되고 운영되고 스프링 프레임워크에서 객체는 Bean이라는 자바 객체로 불린다.
+
+- RestContollerAdvice
+
+    공식 문서에 따르면`RestControllerAdvice = ControllerAdvice + ResponseBody` 
+
+    정리하자면  `RestControllerAdvice` 로 선언하면 컨트롤러에서 리턴하는 값이 응답 값의 body로 세팅되어 클라이언트에게 전달된다.
+
+    즉, 뷰를 렌더링하는 과정 없이 JSON 형태의 응답을 반환한다.
+
+    - RestControllerAdvice의 장점, 불편한 점
+        - 장점
+            - HttpServletRequest나 WebRequest 등을 얻을 수 있으며 반환 타입으로는 ResponseEntity, String, void 등 자유롭게 활용할 수 있음
+            - 컨트롤러에서 예외를 직접 처리하지 않아도 됩니다.
+
+                예외가 발생하면 `@(Rest)ControllerAdvice`가 선언된 클래스에서 해당 예외를 캐치하고 적절한 응답을 반환합니다.
+
+            - 예외에 따라 다른 처리 로직을 적용할 수 있습니다.
+
+                `@ExceptionHandler` 어노테이션을 사용하여 특정 예외에 대한 `핸들러 메서드`를 정의할 수 있습니다.
+
+                예를 들어, NullPointerException이 발생하면 400 에러 코드와 에러 메시지를 반환하고, IOException이 발생하면 500 에러 코드와 에러 메시지를 반환하는 등의 로직을 구현할 수 있습니다.
+
+            - 공통적인 예외 처리 로직을 재사용할 수 있습니다.
+
+                `@(Rest)ControllerAdvice`가 선언된 클래스는 모든 컨트롤러에 적용됩니다. 따라서 여러 컨트롤러에서 발생하는 동일한 예외에 대해 한 곳에서 처리할 수 있습니다.
+
+        - 없으면 불편한 점
+            - `ControllerAdvice` 는 리턴값을 기준으로 동일한 이름의 view를 찾는다.  만약 동일한 뷰가 없다면 에러가 난다.
+            - `ControllerAdvice` 에서 `ResponseBody` 어노테이션을 붙이면 `RestControllerAdvice`와 같은 역할을 하지만 불편하다.
+            - 각 컨트롤러마다 예외 처리를 개별적으로 구현해야 하므로, 동일한 예외 처리 코드가 여러 컨트롤러에 중복될 가능성이 높다. 이는 코드 유지보수성을 떨어뜨리고, 코드의 일관성을 유지하기 어렵게 만든다.
+            - 예외 처리 로직을 변경해야 할 경우, 모든 컨트롤러에서 해당 로직을 일일이 찾아 수정해야 하므로 많은 시간과 노력이 필요하며, 실수로 일부 컨트롤러에서 수정이 누락될 위험이 있다..
+
+
+        `ControllerAdvice` 는 리턴값을 기준으로 동일한 이름의 view를 찾는다. 여기서는 그 뷰가 없기 때문에 에러가 난다.
+
+        `ControllerAdvice` 는 리턴값을 기준으로 동일한 이름의 view를 찾는다. 여기서는 그 뷰가 없기 때문에 에러가 난다.
+
+        `ControllerAdvice` 는 리턴값을 기준으로 동일한 이름의 view를 찾는다. 여기서는 그 뷰가 없기 때문에 에러가 난다.
+
+        `ControllerAdvice` 는 리턴값을 기준으로 동일한 이름의 view를 찾는다. 여기서는 그 뷰가 없기 때문에 에러가 난다.
+
+        `ControllerAdvice` 는 리턴값을 기준으로 동일한 이름의 view를 찾는다. 여기서는 그 뷰가 없기 때문에 에러가 난다.
+
+- lombok
+    - 반복적으로 사용되는 코드의 작성을 자동화하여 코드양을 줄이고 가독성을 높여주는 라이브러리
+    - 기능: model 클래스나 Entity 같은 도메인 클래스 등에 반복되는 getter, setter, toString 등의 메소드를 자동으로 만들어줌
+    - 자주 사용되는 Lombok 어노테이션
+        - @NorgsConstructor : 파라미터가 없는 기본 생성자를 만들어줌
+        - @AllArgsConstructor : 모든 필드 값을 파라미터로 받는 생성자를 만들어줌
+        - @RequiredArgsConstructor : final이나 @NonNull 인 필드 값만 파라미터로 받는 생성자를 만들어줌
+        - @EqualsAndHashCode : equals와 hashcode를 자동으로 생성해주는 어노테이션
+        - @Builder : 자동으로 해당 클래스에 빌더를 추가해줌
+    - 이처럼 빌더패턴에 필수적인 라이브러리

src/mission/chapter8/mission8

@@ -0,0 +1,46 @@
+- **미션 기록**
+    - ⚡이슈 No.1
+
+        **`이슈`**
+
+        👉 [ErrorStatus 작성]
+
+        **`문제`**
+
+        👉 [ErrorStatus에서 enum이 워크북대로 했는데도 오류가 남]
+
+        **`해결`**
+
+        👉  [AllArgsConstructor 애노테이션을 사용하면 지역변수가 선언되어 있는 순서대로 생성자를 만든다
+
+        → 따라서 매개변수 순서대로 지역변수를 선언해주면 해결]
+
+        **`참고레퍼런스`**
+
+        - [이것저것 해봄]
+    - RestControllerAdvice의 장점, 불편한 점
+        - 장점
+            - HttpServletRequest나 WebRequest 등을 얻을 수 있으며 반환 타입으로는 ResponseEntity, String, void 등 자유롭게 활용할 수 있음
+            - 컨트롤러에서 예외를 직접 처리하지 않아도 됩니다.
+
+                예외가 발생하면 `@(Rest)ControllerAdvice`가 선언된 클래스에서 해당 예외를 캐치하고 적절한 응답을 반환합니다.
+
+            - 예외에 따라 다른 처리 로직을 적용할 수 있습니다.
+
+                `@ExceptionHandler` 어노테이션을 사용하여 특정 예외에 대한 `핸들러 메서드`를 정의할 수 있습니다.
+
+                예를 들어, NullPointerException이 발생하면 400 에러 코드와 에러 메시지를 반환하고, IOException이 발생하면 500 에러 코드와 에러 메시지를 반환하는 등의 로직을 구현할 수 있습니다.
+
+            - 공통적인 예외 처리 로직을 재사용할 수 있습니다.
+
+                `@(Rest)ControllerAdvice`가 선언된 클래스는 모든 컨트롤러에 적용됩니다. 따라서 여러 컨트롤러에서 발생하는 동일한 예외에 대해 한 곳에서 처리할 수 있습니다.
+
+        - 없으면 불편한 점(구글링은 잘 안나와서 지피티 돌려봤습니다)
+            1. **중복 코드 증가**:
+                - 각 컨트롤러마다 예외 처리를 개별적으로 구현해야 하므로, 동일한 예외 처리 코드가 여러 컨트롤러에 중복될 가능성이 높습니다. 이는 코드 유지보수성을 떨어뜨리고, 코드의 일관성을 유지하기 어렵게 만듭니다.
+            2. **유지보수 어려움**:
+                - 예외 처리 로직을 변경해야 할 경우, 모든 컨트롤러에서 해당 로직을 일일이 찾아 수정해야 합니다. 이는 많은 시간과 노력이 필요하며, 실수로 일부 컨트롤러에서 수정이 누락될 위험이 있습니다.
+            3. **일관성 부족**:
+                - 예외 처리 방식이 컨트롤러마다 다를 수 있어, 클라이언트가 예외 상황을 예측하기 어렵습니다. 이는 API의 일관성을 떨어뜨리고, 사용자 경험을 저해할 수 있습니다.
+            4. **글로벌 설정의 어려움**:
+                - **`RestControllerAdvice`**를 사용하면 특정 예외에 대한 전역적인 처리를 한 곳에서 설정할 수 있어 편리합니다. 이를 사용하지 않으면 전역 설정이 어려워지고, 특정 예외에 대한 일관된 처리가 어려워집니다.