레이어드 아키텍처 패턴
- 스프링 프로젝트 내부에서 어떻게 코드를 적절히 분리하고 관리할 것이냐에 대한 것으로, 애플리케이션을 구성하는 요소들을 수평으로 나눠 관리하는 것
- 레이어로 나눈다는 것은 메서드를 클래스 또는 인터페이스로 쪼개는 것으로, 각 레이어 사이에는 계층이 있고 레이어는 자기보다 한 단계 하위의 레이어만을 사용한다.
- 보통 자바로 된 비즈니스 애플리케이션의 클래스는 비즈니스 로직을 수행하는 클래스와, 데이터를 담는 클래스로 나눌 수 있다.
- 비즈니스 로직을 수행하는 클래스는 컨트롤러, 서비스, 리포지토리처럼 로직을 수행한다.
- 데이터를 담는 클래스는 아무 기능 없이 데이터베이스에서 반환된 비즈니스 데이터를 담고 있으며, 기능에 따라 엔티티, 모델, DTO 등으로 부른다.
모델, 엔티티, DTO
- 모델은 비즈니스 데이터를 담는 역할을 하며, 엔티티는 데이터베이스의 테이블과 스키마를 표현하는 역할을 한다.
- 규모가 작은 프로젝트에서는 보통 모델과 엔티티를 합쳐서 구현한다.
- 서비스가 요청을 처리하고 클라이언트로 반환할 때 모델 자체를 그대로 리턴하는 것이 아니라, 데이터 전달 오브젝트인 DTO로 변환해 리턴한다.
- Why??
- 비즈니스 로직 캡슐화: 모델은 데이터베이스 테이블 구조와 유사하기 때문에, 다른 오브젝트로 바꿔 반환해서 외부 사용자에게 서비스 내부의 로직, 데이터베이스의 구조 등을 숨긴다.
- 클라이언트가 필요한 정보를 모델이 전부 포함하지 않는 경우가 많다. (예 - 에러 메시지)
REST 아키텍처 스타일
- 클라이언트가 서비스를 이용하려면 어떤 형식으로 요청을 보내고 응답을 받는지에 대한 것
- 아키텍처 패턴은 어떤 반복되는 문제 상황을 해결하는 도구이고, 아키텍처 스타일은 반복되는 아키텍처 디자인을 의미한다.
REST 아키텍처 스타일 제약조건
- 클라이언트-서버
- stateless
- 캐시되는 데이터
- 일관적인 인터페이스
- 레이어 시스템
- 코드-온-디맨드 (선택사항)
→ 제약 조건에 맞춰 REST 아키텍처 스타일을 따라 설계 및 구현된 서비스를 RESTful 서비스라고 한다.
1. 클라이언트-서버
- 리소스를 관리하는 서버가 존재하고 다수의 클라이언트가 리소스를 소비하려고 네트워크를 통해 서버에 접근하는 구조로, 웹 애플리케이션이 대표적인 예
- 리소스란 REST API가 리턴할 수 있는 모든 것을 의미한다. (HTMP, JSON, 이미지 등)
2. stateless
- 상태가 없다는 것은 클라이언트가 서버에 요청을 보낼 때 이전 요청의 영향을 받지 않음을 의미한다.
- 상태를 유지하기 위해서는 클라이언트가 서버에 요청을 할 때마다 요청에 리소스를 받기 위한 모든 정보를 포함해야 한다.
- 리소스를 수정한 후 수정한 상태를 유지해야 하는 경우에는 서버가 아닌 데이터베이스 같은 퍼시스턴스에 상태를 저장해야 한다.
- HTTP는 기본적으로 상태가 없는 프로토콜로, HTTP를 사용하는 웹 애플리케이션은 기본적으로 상태가 없는 구조를 따른다.
3. 캐시되는 데이터
- 서버에서 리소스를 리턴할 때 캐시가 가능한지 아닌지 명시할 수 있어야 한다.
- HTTP에서는 cache-control이라는 헤더에 리소스의 캐시 여부를 명시할 수 있다.
4. 일관적인 인터페이스
- 시스템 또는 애플리케이션의 리소스에 접근할 때 인터페이스가 일관적이어야 한다. (리소스에 접근하는 방식, 요청 형식, 응답 형식)
- 즉 URI, 요청과 응답의 형태가 애플리케이션 전반에 걸쳐 일관적이어야 한다는 의미
- 또한 서버가 리턴하는 응답에는 해당 리소스를 수정할 수 있는 충분한 정보가 있어야 한다.
5. 레이어 시스템
- 클라이언트가 서버에 요청할 때 여러 개의 레이어로 된 서버를 거칠 수 있다. (예를 들어, 서버가 인증 서버, 캐싱 서버, 로드 밸런서를 거쳐서 최종적으로 애플리케이션에 도착하는 경우)
- 이 사이의 레이어들은 요청과 응답에 어떤 영향도 미치지 않으며, 클라이언트는 서버의 레이어 존재 유무를 알지 못해야 한다.
6. 코드-온-디맨드
- 클라이언트는 서버에 코드를 요청할 수 있고 서버가 리턴한 코드를 실행할 수 있다.
※ 참고: REST는 HTTP를 이용해 구현하기 쉽고 대부분 그렇게 구현하지만 엄밀히 말하면 REST는 아키텍처이고, HTTP는 REST 아키텍처를 구현할 때 사용하면 쉬운 프로토콜
'Spring > Rest API' 카테고리의 다른 글
REST 서비스 사용 (0) | 2022.01.30 |
---|---|
스프링 데이터 REST (0) | 2022.01.30 |
REST 엔드포인트 정의 (0) | 2022.01.30 |
RestContoller 요청과 응답 방법 (0) | 2022.01.20 |
REST API 인증 기법 (0) | 2022.01.20 |