프로젝트하며 공부한 내용

rest 아키텍쳐 패턴은 스프링 프로젝트 내부에서 어떻게 코드 적절히 분리하고 관리 할것인가

 

rest아키텍처 스타일은 클라이언트(브라우저)가 우리 서비스를 이용하려면 어떤 형식으로 요청을 보내고 응답 받는지에 대한 것, 이러한 rest 아키텍쳐 스타일을 따라 설계된 서비스를 restful 서비스라 칭함

 

레이어는 사이에 계층이 존재해 자기보다 한단계 낮은 레이어만 사용한다

-컨트롤러가 요청을 받고

컨트롤러는 서비스를 사용, 서비스는 퍼시스턴스를 사용, 퍼시스턴스는 요청한 데이터를 반환 서비스는 다시 데이터 검토 후 가동후 반환 컨트롤러 또한 같은 작업 

 

 

자바로된 비즈니스 app의 클래스는 보통 두가지 

기능을 수행하는 서비스와, 데이터를 담는 서비스

기능을 수행하는 서비스는 컨트롤러, 서비스, 퍼시스턴스 로직을 구현하는데 사용 

 

아무 기능없이 데이터 베이스에서 반환된 비즈니스 데이터 담기 위한 클래스를 기능에 따라 엔티티,모델,DTO라 부름

---

어노테이션

 

@Builder는 오브젝트 생성을 위한 디자인 패턴, 롬복이 제공하는 @Builder 어노테이션을 사용하면 Builder클래스를 따로 개발하지 않고도 패턴을 Builder 패턴을 사용해 오브젝트를 생성 할 수 있음

-> 생성자를 이용해 오브젝트 생성하는 것과 비슷함, 생성자 매개변수의 순서를 기억할 필요도 없음

 

@NoArgsConstructor 

매개변수가 없는 생성자를 구현

 

@AllArgsConstructor

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

 

@Data

클래스 멤버의 getter/getter 메서드 구현

---

DTO

서비스가 요청을 처리하고 클라이언트로 반환할 떄 모델 자체를 그대로 리턴하는 경우는 별로 없다

보통 데이터 전달하는데 사용하는 오브젝트인 DTO(data transfer object)로 변환해 리턴 

왜?

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

모델은 데이터 베이스 테이블 구조와 매우 유사 모델이 갖고 있는 필드들은 테이블의 스키마와 비슷할 확률이 높음

대부분의 비즈니스는 외부인이 자사의 데이터베이스 스키마를 아는것을 원치 않을테니 , DTO같은 다른 오브젝트로 변환하여 반환하면 외부 사용자에게 숨길 수 있으니까..!

 

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

대표적으로 에러메세지

만약 서비스 실행 도중 사용자 에러가 난다면 이 에러 메세지를 어디에 포함해야 할까...?

모델은 서비스 로직과는 관련이 없기에 모델에 담기엔 애매... 따라서 DTO에 에러메세지 필드 선언하고 포함 시키는것 

---

REST API

 

-Representatinal State Transfer 의 약자, 아키텍처 스타일임

아키텍처 패턴이 어떤 반복되는 문제 상황을 해결하는 도구라면 아키텍처 스타일은 반복되는 아키텍처 디자인을 의미

 

REST아키텍처 스타일은 6가지 제약조건을 가지고, 이 가이드 라인을 따르는 API를 Restfull API라함

-클라이언트 -서버

- 상태가 없는 

- 캐시되는 데이터

-일관적인 인터페이스

-레이어 시스템

-코드-온-디맨드 

 

클라이언트-서버

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

(리소스란? Rest API가 리턴할 수 있는 모든 것 ex) HTML, JSON, 이미지 등)

 

상태가없는

상태가 없다 = stateless는 클라이언트가 서버에 요청을 보낼 떄 이전 요청의 영향을 받지 않음을 의미 

ex)  /login으로 로그인 요청을 보내고 로그인이 돼 다음 페이지인 /page로 넘어 갔다 가정, /page로 리소스 불러올 때 이전 요청에서 login한 사실을 서버가 알고 있어야 한다면 상태가 있는 stateful 아키텍처다, 서버가 그 사실을 알지 못한다면 stateless 상태가 없는것 

그럼 로그인을 어떻게 하라는??? 상태 유지는 어떻게 하라는??

클라이언트는 서버에 요청을 할때마다 요청에 리소스를 받기위한 모든 정보를 포함해야함

ex) 로그인의 경우 서버는 로그인 상태를 유지하지 못하므로 요청을 보낼 때 마다 로그인 정보를 항상 함께 보내야 함 

리소를 수정 한 후 수정한 상태를 유지해야하는 경우 서버가 아닌 데이터 베이스에 퍼시스턴스에 상태를 저장해야함 

HTTP는 기본적으로 상태가 없는 프로토콜, 

 

캐시되는 데이터

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

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

 

일관적인 인터페이스

일관적인 인터페이스라는 것은 애플리케이션 리소스에 접근할 때 인터페이스가 일관적이여야함을 의미

ex) 아이템을 가져오려고, http://tyhan02.tistory 를 사용 , 이때 아이템을 업데이트할 때 http://tyhan03.tistory 을 사용해야하면 일관성이 깨지는 것 (URL의 일관성)

이와같이 리소스에 접근하는 방식, 요청 형식, 응답 형식, URL, 요청의 형태와 응답의 형태가 애플리케이션 전반에 걸쳐 일관적이여야 함

 

레이어 시스템

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

서버가 인증서버, 캐싱서버, 로드 밸런서를 서쳐 최종적으로 애플리케이션에 도착한다고 가정할 때 

이 사이의 레이어 들은 요청과 응답에 어떤 영향을 미치지 않으며 클라이언트는 서버의 레이어 존재 유무를 알지 못함

 

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

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

 

REST는 HTTP와 다르다 rest는 HTTP를 이용해 구현하기 쉽고 대부분 그렇게 구현하지만, REST는 아키텍처, HTTP는 REST아키텍처를 구현할때 사용하면 쉬운 프로토콜

---