학습목표
강의를 들으며 내가 알고 있는 내용을 점검하고,
새로 배운 내용을 정리하며,
궁금한 내용을 알아가며 학습해나가는 것을 목표로 합니다.
WebApplicationContext
애플리케이션 컨텍스트를 상속하고 있으며, 서블릿 컨텍스트에 접근할 수 있는 기능(getServletContext())이 추가된 인터페이스 입니다.
서블릿 컨텍스트는 서블릿 컨테이너에 의해서 만들어지는데, 여러 서블릿이 공유가 가능한 정보를 담고 있는 객체입니다.
결국 웹 스프링에서는 두 가지 어플리케이션 컨텍스트가 존재하고, 웹과 관련된 UI성 빈은 웹 어플리케이션 컨텍스트에 등록하여 사용합니다.
이렇게 컨텍스트를 분리함으로써 Web 기술과 도메인을 분리하며, 의존 방향이 역전되거나 상호 의존하는 상황을 막고, AOP가 적용되는 범위를 제한할 수 있습니다.
ContextLoaderListener
계층별로 나눈 xml 설정 파일이 있다고 가정할 때, web.xml에서 모두 load 되도록 등록할 때 사용합니다.
서블릿 이전에 서블릿을 초기화 하는 용도로 쓰이며, contextConfigLocation 파라미터를 사용하면 contextLoader가 load할 수 있는 설정 파일을 여러 개 쓸 수 있습니다.
RootApplicationContext를 생성하는 클래스입니다.
웹 환경에서 스프링 애플리케이션이 동작하는 방식
REST(ful) API
REST
REpresentational State Transfer는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식입니다.
로이 필딩의 2000년 박사 학위 논문에소 소개 되었고, 필딩은 HTTP의 주요 저자 중 한 사람입니다.
엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음입니다.
여기서 ‘네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법을 뜻 합니다.
즉 REST의 가장 기본적인 규칙은 URI는 자원을 표현하는데 집중하고 행위에 대한 정의는 HTTP Method를 통해 하는 것이 REST한 API를 설계하는 중심 규칙입니다.
간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 뜻 합니다.
API
API는 다양한 소프트웨어 컴포넌트들과 통신을 하기 위해 정의된 방법입니다.
즉 REST API는 REST 아키텍처 스타일을 따르는 API 입니다.
REST 아키텍처 스타일
-
클라이언트-서버 (client-server)
- 사용자 인터페이스에 대한 관심을 데이터 저장에 대한 관심으로부터 분리하여 클라이언트의 이식성과 서버의 규모확장성을 개선합니다.
-
무상태 (stateless)
- 클라이언트와 서버의 통신 간의 상태가 존재하지 않습니다.
- 모든 요청에는 필요한 모든 정보를 담고 있어 가시성이 좋고, 요청 실패 시 복원이 쉽기 때문에 신뢰성이 보장됩니다.
- 상태를 저장할 필요가 없어 규모확장성이 개선됩니다.
-
캐시 (cache)
- 캐시가 가능해야 합니다.
- HTTP가 가진 캐싱 기능이 적용 가능하며, HTTP 프로토콜 표준에서 사용하는 Last-modfied 태그나 E-Tag등을 통하여 캐싱 구현이 가능합니다.
-
균일한 인터페이스 (uniform interface)
-
URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말합니다.
- Identification of resources
- manipulation of resources through represenations
- self-descrive messages
-
-
계층화된 시스템 (layered system)
- REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 Proxy, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.
-
Code-on-Demand (Optional)
- 서버에서 코드를 클라이언트로 보내서 실행 가능합니다.
Richardson Maturity Model
(https://martinfowler.com/articles/richardsonMaturityModel.html)
- Level 0
- SOAP 방식, 혹은 그냥 HTTP로 통신만 가능합니다.
- 하나의 엔드포인트만 존재하며 하나의 URL로 xml를 주고 받으며 통신합니다.
- Level 1
- 리소스 단위로 여러개의 엔드포인트가 존재합니다.
- Level 2
- 리소스의 사용 목적에 맞게 HTTP method를 사용합니다.
- Level 3
- HATEOAS라는 개념을 통해 해당 자원에 대해 호출 가능한 API에 대한 정보를 자원의 상태를 반영하여 표현합니다.
Representations
하나의 리소스가 다양한 방식으로 표현 될 수 있다는 것을 의미합니다.
어떠한 리소스의 특정 시점의 상태를 반영하고 있는 정보이며 representation data와 representation metadatah로 구성되어 있습니다.
HATEOAS
Hypermedia As The Engine of Application State (hey-dee-us)
접근 가능한 API들에 대한 정보를 추가적으로 제공합니다.
이를 통해 클라이언트는 해당 기능의 실행 가능 여부 및 실행하기 위해 필요한 데이터를 알 수 있게 되며,
API 개발자들은 API 엔드포인트를 제외한 나머지 URL들을 수정할 수 있습니다.
즉, 링크 정보를 동적우로 바꿀 수 있습니다.
API 설계 규칙
-
URI는 정보의 자원을 표현해야 합니다.
리소스명은 동사보다는 명사를 사용합니다.
-
자원에 대한 행위는 HTTP method로 표현합니다.
-
슬래시 구분자(/)는 계층 관계를 나타내는데 사용합니다.
-
URI 마지막 문자로 슬래시(/)를 포함하지 않습니다.
-
하이픈(-)은 URI 가독성을 높이는데 사용합니다.
RestController
HTTP 메세지 컨버터
