FeedBack_Study

ResponseEntity
- 정의 : 스프링 프레임워크에서 제공하는 클래스.
- Http요청 또는 응답에 해당하는 HttpStatus, HttpHeader와 HttpBody를 포함하는 클래스
- Http 응답의 주권을 가짐. 커스텀 가능
- 상속 구현 클래스 (RequestBody, ResponseEntity)

기존 상태
- 클라이언트 측에서는 ApiResponse로 응답시 정해진 응답 (예 : 200이면 200, 500이면 500)
- 현재 ApiResponse 클래스는 정적 팩토리 메서드 형식.
- ApiResponse.java
  ```
  //성공한 경우
    public static <T> ApiResponse<T> onSuccess(BaseSuccessCode code, T result){
    return new ApiResponse<>(true, code.getCode(), code.getMessage(), result);
    }
  ```
기존 방식의 한계
- 클라이언트 측은 먼저 http status를 확인하고 바디를 확인함
- 네트워크 불일치 : ApiResponse만 반환하면 내부 로직이 실패하더라도 Http 상태코드는 기본(200)으로 나가는 경우가 많았음
- 상세한 정보가 Json바디 안에 숨겨져 있어 클라이언트가 Http 표준방식으로 1차 판단을 내리기 어려웠음
- 단순한 소통 : 200, 500 위주의 단순한 소통만 가능했고, 201, 204 등 을 활용 못했음

Why?
- API 사용자(프론트엔드 등등)는 응답바디 안의 Json뿐 아닌 브라우저나 앱이 수신하는 Status Code를 보고 1차 판단을 내림.
- 유연성 : ResponseEntity를 래핑해 감싼 응답을 보낸다면 커스텀 응답, 쿠키, 헤더 등 표준화된 응답을 유연하게 보낼 수 있음.
- ApiResponse의 데이터 규격을 유지하고 ResponseEntity로 감싸 네트워크 수준 상태코드로 명시적 관리