스프링 입문 3.2 REST

REST : Representational State Transfer (자원의 상태 전달)

- 네트워크 아키텍처

 

아래의 6가지의 아키텍처 - 를 잘 지켰는가를 가지고 REST Ful하다고 표현함

1. Client, Server

- 클라이언트와 서버는 서로 독립적으로 분리되어있어야 함

 

2. Stateless

- 요청에 대해 클라이언트의 상태를 서버에 저장하지 않음

 

3. Cache

- 캐시기능이 있어야함 : 클라이언트는 서버의 응답을 임시저장(Cache) 할 수 있어야 함

- 클라이언트가 캐시를 통해서 응답을 재사용할수 있어야함 -> 이를통해 서버의 부하를 낮춤 (요즘엔 서버쪽에서도 캐시기능을 활용해서  중복된데이터의 경우 캐시된 데이터를 내려주기도 함)

 

4. 계층화(Layered System)

- 서버와 클라이언트 사이 방화벽, 게이트웨이, Proxy서버 등 여러 다양한 서버가 추가될수있기때문에 이들을 계층형태로 구성할수있어야하며, 이를 확장할수있어야함

 

5. 인터페이스 일관성

- 인터페이스 일관성을지키고, 아키텍처를 단순화시켜 작은단위로 분리하여 -> 클라이언트, 서버가 독립적으로 개선될수 있어야함

 

6. Code on Demand(optional)

- 자바애플릿, 자바스크립트, 플래시등 특정기능을 서버로부터 클라이언트가 전달받아 클라이언트가 코드를 실행할 수 있어야 함 - ex) 자바스크립트 : 서버로부터 HTML, JAVASCRIPT, CSS 파일을 가져와서 화면을꾸민뒤 자바스크립트가 실행되며 서버로부터 데이터 받아와서 데이터를 보충하는 형태로 프론트개발이 이루어지고 있음

 

 

다음 인터페이스 일관성이 잘 지켜졌다면, REST를 잘 사용했는지 판단할수있음

1. 자원의 식별

- 웹기반의 REST에서는 리소스 접근시 URI 사용함

- URI에 자원을 식별할수있는 정보가 담겨 있어야 함

- ex) https://naver.co.kr/user/100 -> Resource : user, 식별자 : 100

 

2. 메시지를 통한 리소스 조작

- 웹에서의 데이터전달방식 : HTML, XML , JSON, TEXT 등등 -> 이중 어떤 데이터 타입인지 알려주기위해 HTTP Header 부분에 content-type통해 데이터 타입을 지정

- 리소스 조작을위해 데이터전체를 전달x, 메시지로 전달함

 

3. 자기 서술적 메시지

- 요청하는 데이터가 어떻게 처리되어져야 하는지 충분한 데이터를 포함해야함

- HTTP기반 REST에서는 HTTP Method와 Header 정보, URI의 포함되는 정보로 표현할수있음 (그외 담지못한 정보들은 URI메시지를 통해 표현)

 

4. 애플리케이션 상태에 대한 엔진으로써 하이퍼미디어

- REST API 를 개발할때, 단순히 한가지 클라이언트의 요청에 대한 응답을 해주는것이 아닌, 서버가 가지고 있는 관련된 리소스에 대한 Link정보까지 같이 포함되어야 함 

- 현업에서는 잘 사용하지 않음 : 이유) 클라이언트 개발시 서버의 API스펙을 보고 데이터클래스를 만들어서 맵핑을 하게 됨 -> 만약 이런 주소정보까지 맵핑하면 실제 서버로부터 받아오는 데이터 외 다른 불필요정보까지도 작성해야하기 때문

 

-> 이러한 조건들을 잘 갖춘 경우 REST Ful하다고 표현하고, 이를 REST API라고 함