Rest 란?

RESTful

- REpresentational State Transfer의 약자

- 2000년도 Roy Fielding의 박사학위 논문에 최초로 소개됨

- 인터넷에서 자원에 접근(Access)하는 방법을 정의하는 네트워크 기반 아키텍쳐

- URI 와 HTTP 메소드를 이용해 객체화 된 서비스에 접근 하기 위한 서버와 클라이언트 사이의 통신 방식

- 소프트웨어 아키텍처의 한 형식

정의

HTTP URI로 잘 표현된 리소스에 대한 행위를 HTTP Method로 정의한다

리소스 내용은 JSON,XML,YAML등의 다양한 표현 언어로 정의된다 

구성요소

Resource

- 처리되는 대상을 의미

- REST에서 가장 중요한 개념은 유일한 ID를 가지는 Resource가 서버에 존재하고 클라이언트는 각 Resource의 상태를 조작하기 위해 요청을 보낸 다는 것이다

- Resource는 URI(Uniform Resource Identifier, 통합 자원 식별자)로 정의된다

- 일반적으로 Resource는 명사형의 단어이다

Method

- Rest API에서는 리소스에 대한 행위가 일관되게 정의된다 즉 REST API로 다루는 대상 Resource가 무엇이든 같은 메소드에 의해 다뤄진다

- POST , GET , PUT , PATCH , DELETE등이 있다

- 위의 HTTP Method에 순서대로 매핑되는 CRUD연산은 CREATE , READ , UPDATE /Replace , UPDATE/Modify , DELETE 이다

Representation

- 클라이언트가 서버로 요청을 보냈을 때 , 서버가 응답으로 보내주는 Resource의 상태를 Representation이라고 한다

- REST API에서는 하나의 Resource가 여러개의 Representation으로 나타내어 질 수 있다

- ex) JSON,XML,TEXT,RSS 등

URI 구성

- URI는 직관적으로 어떤 정보를 제공하는지 알 수 있는 단어들로 구성

- URI는 path가 계층적인 구조를 가지도록 구성

- CRUD 처리는 URI에 명시적으로 표현하여 URI를 보더라도 직관적으로 어떤 기능을 제공하는지 알 수 있도록 명명

특징

1) Uniform

- REST API는 리소스의 종류에 상관없이 동일한 API 메소드를 갖는다

ex ) 이미지 Resource에 대한 처리와 문서 Resource에 대한 처리가 일관된 형태로 요청

2) Stateless

- REST API를 제공하는 서버측에서 수행의 문맥을 저장하지 않는다

- 이전에 어떤 요청을 요청했는지 저장하지 않고 각 REST API는 독립적으로 처리

- 문맥 처리가 필요하다면 클라이언트가 자체적으로 관리하며 세션 정보를 서버에 유지하지 않는다

3) Cacheable

- HTTP프로토콜을 사용하기 떄문에 기존 웹 인프라를 그대로 사용가능

- HTTP 캐시 이용가능

- URI를 매번 요청 하지 않고 클라이언트의 HTTP 캐시에서 미리 가져온 정보 반환

4) Self-Descriptiveness

- REST API 메세지 그 자체로 쉽게 이해할 수 있어야 한다

- 별도의 주석이나 문서가 없어도 특정 REST API가 원하는 바를 쉽게 이해할 수 있어야 한다

5) Client-Server Architecture

- REST API 서버는 클라이언트에게 API를 제공하기만 한다 서버는 클라이언트의 실행 문맥(Execution Context)를 알고 있을 필요가 없이 독립적인 REST API에 대한 서비스만 제공하면 된다

- 클라이언트와 서버의 역할 분담이 명확하게 분리

6) Layered System

- REST API는 Multi-layer로 구성될 수 있다 클라이언트는 대상 서버에 직접 붙었는지 중간에 존재하는 서버와 통신하는지 알 수 없다 중간에 존재하는 서버를 이용하여 Security관리,Encrypt,Load Balancing 등을 수행할 수 있어 확장성 및 보안 향상이 가능하다

7) Code on Demand

- REST API는 서버에서 수행 스크립트를 받아서 클라이언트 사이드 수행을 할 수도 있다

RESTful

이러한 REST API의 설계 의도를 정확하게 지켜주는 API를 'RESTful 하다'라고 한다

RESTful한 API는 구성요소들의 역할이 명확하게 분리되어 있어야 한다 

URI는 자원을 정확하고 , 인식하기 편하게 표현하는데 집중하고 자원에 대한 행위는 Uniform 하게 HTTP메소드를 통해 정의를 한다 나머지 load는 JSON 이나 XML, YAML같은 언어를 이용하여 별도로 정의한다

단점

- HTTP 메소드 한계에 묶인다

- 표준이 없어 관리하기 어렵다

- RDBMS와 어색하다

: NoSQL이 더 잘 어울림