p.83 ~ 109

레이어드 아키텍처 패턴

스프링 프로젝트 내부에서 어떻게 코드를 적절히 분리하고 관리할 것이냐에 대한 것

 

REST 아키텍처 스타일

클라이언트(브라우저)가  우리 서비스를 이용하려면 어떤 형식으로 요청을 보내고 응답을 받는지에 대한 것

Rest 아키텍처 스타일을 따라 설계 및 구현된 서비스를 RESTful 서비스라고 한다.

 

보통 자바로 된 비즈니스 애플리케이션의 클래스는 두 가지 종류로 나눌 수 있다

1. 일을 하는 클래스 = 기능을 수행하는 클래스(컨트롤러, 서비스, 퍼시스턴스)

2. 데이터를 담는 클래스 (엔티티, 모델, DTO)

 

롬복 어노테이션 설명

@Builder

Builder 클래스를 따로 개발하지 않고도 Builder 패턴을 사용해 오브젝트를 생성할 수 있다.

생성자를 이용해 오브젝트를 생성하는 것과 비슷하다. 생성자 매개변수의 순서를 기억할 필요가 없다.

사용방법

TodoEntity todoEntity = TodoEntity.builder()
        .id("id-11")
        .userId("developer")
        .title("게시물")
        .build();

 

@NoArgsConstructor

매개변수가 없는 생성자를 구현해 준다.

 

@AllArgsConstructor

클래스의 모든 멤버 변수를 매개변수로 받는 생성자를 구현해 준다.

 

@Data

클래스 멤버 변수의 Getter/Setter 메서드를 구현해 준다.

 

DTO

사용이유

1. 비즈니스 로직을 캡슐화 하기 위해

2. 클라이언트가 필요한 정보를 모델이 전부 포함하지 않는 경우가 많기 때문에

 

REST API

REST 아키텍처 스타일은 6가지 제약조건으로 구성된다. 이 가이드 라인을 따르는 API를 RESTful API라고 한다.

REST 제약조건

1. 클라이언트 - 서버

2. 상태가 없는

3. 캐시되는 데이터

4. 일관적인 인터페이스

5. 레이어 시스템

6. 코드-온-디맨드 (선택사항)

 

클라이언트 - 서버

리소스를 관리하는 서버가 존재하고 다수의 클라이언트가 리소스를 소비하려고 네트워크를 통해 서버에 접근하는 구조

리소스: REST API가 리턴할 수 있는 모든 것(HTML, JSON ..)

 

상태가 없음

클라이언트가 서버에 요청을 보낼 때 이전 요청의 영향을 받지 않음을 의미

HTTP는 기본적으로 상태가 없는 프로토콜이다.

 

캐시되는 데이터

서버에서 리소스를 리턴할 때 캐시가 가능한지 아닌지 명시할 수 있어야 한다.

HTTP에서는 cache-control이라는 헤더에 리소스의 캐시 여부를 명시할 수 있다.

 

일관적인 인터페이스

시스템 또는 애플리케이션의 리소스에 접근할 때 인터페이스가 일관적이어야 한다.

리소스에 접근하는 방식, 요청 형식 그리고 응답 형식 즉 URI 요청의 형태와 응답의 형태가 애플리케이션 전반에 걸쳐 일관적이어야 한다는 것이 일관적인 인터페이스 방침이다.

 

레이어 시스템

클라이언트가 서버에 요청을 할 때 여러 개의 레이어로 된 서버를 거칠 수 있다.

(인증 서버 - 캐싱 서버 - 로드 밸런서)

클라이언트는 서버의 레이어 존재 유무를 알지 못한다.

 

코드-온-디맨드(선택 사항)

클라이언트는 서버에 코드를 요청할 수 있고 서버가 리턴한 코드를 실행할 수 있다.

 

스프링 부트 스타터 웹의 어노테이션을 이용하면 연결을 쉽게 할 수 있다.

 

@RestController: 현재 컨트롤러가 RestController임을 명시한다.

RestController를 이용하면 http와 관련된 코드 및 요청/응답 매핑을 스프링이 알아서 해준다.

 

@GetMapping: 클라이언트가 이 리소스에 대해 Get 메서드로 요청하면 @GetMapping에 연결된 컨트롤러가 실행된다.

 

@PathVariable: /{id} 와 같이 URI의 경로로 넘어오는 값을 변수로 받을 수 있다.

 

@RequestParam: ?id={id}와 같이 요청 매개변수로 넘어오는 값을 변수로 받을 수 있다.