아직 작성중인 글입니다 :) 불완전한 내용이 포함되어 있을 수 있습니다 ✔️
인터페이스 만들고 구현체 숨기는 구조를 가지면 Service는 컴파일 시점에 어떤 클래스를 담을지 결정하지 않고 런타임 시점에 스프링 컨테이너에 존재하는 Service 구현체 빈 중 하나를 주입받게 됩니다.
가져다 쓰는 Controller 입장에서는 Service가 구현체가 런타임 시점에 지정되므로 Service와 Controller는 느슨한 결합도를 가지게 되어 변경 없이 가져다 쓰고(변경최소화), 재활용성을 향상시켰습니다.
이러한 과정이 SOLID 즉 객체지향의 5가지 원칙 중 OCP를 실행하는 길 입니다
HTTP 에서 동일한 URI 리소스를 다양한 컨텐츠 형식으로 제공하기 위해 사용되는 메커니즘으로 클라이언트와 서버가 서로가 원하는 데이터와 줄 수 있는 데이터를 협상하는 과정입니다
예를 들어 아래와 같이 accept header 에 매칭되는 값으로 데이터를 받습니다
한편 앞선 글에서 볼 수 있듯이 모든 요청은 디스패처 서블릿을 통해 전달되고 디스패쳐 서블릿이 html 형식을 받으면 viewResolver 가 데이터를 전달받으면 HandlerMethodReturnValueHandler 가 작동합니다
이때 왼쪽 화살표의 흐름에서 어떠한 뷰를 선택할 것에 관여하는게 컨텐츠 협상입니다
즉, 클라이언트가 요청한 콘텐츠 형식에 따라 서버는 다른 형식의 뷰를 선택하여 응답합니다. 이때 컨텐츠 협상은 요청 헤더에 포함된 정보를 기반으로 적절한 형식을 결정합니다. 예를 들어, 클라이언트가 JSON으로 응답을 원하면, 서버는 JSON 형식의 뷰를 선택하여 데이터를 반환하게 됩니다. 아래 그림처럼 csv 를 요청하면 TodoCsvView를 html 을 요청하면 ThymeleafView를 반환합니다
iso-8859-1 은 서유럽 언어 인코딩을 지원하기 때문에 한글을 표시할 때 깨지는 문제가 발생하기에 한글을 다룰때는 유니코드인 UTF-8 사용을 권장
인코딩은 항상 골칫덩어리였지만 이번기회를 통해 인코딩의 다양한 방식을 배울 수 있었습니다.
스프링을 사용하면 외부 설정 정보인 yml 파일로 인코딩 문제를 해결하였습니다