REST & RESTful & REST API

REST 정의

 

- REST는 Representational State Transfer이라는 용어의 약자로 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처

 

- 웹에 존재하는 모든 자원(이미지, 동영상, DB 자원 등)에 고유한 URI를 부여해 활용하는 것으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법론

 

- 자원의 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미

 

- 자원(Resource)의 표현(Representation)에 의한 상태 전달

• 자원(Resource)의 표현(Representation)

  * 자원 : 해당 소프트웨어가 관리하는 모든 것 (Ex. 문서, 그림, 데이터, 해당 소프트웨어 자체 등등)

  * 자원의 표현 : 그 자원을 표현하기 위한 이름 (Ex. DB의 학생 정보가 자원일 때 ’Students’를 자원의 표현으로 정함)

• 상태(정보) 전달

  * 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달

  * JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적

 

- REST 아키텍처는 Hypermedia API의 기본을 충실히 지키면서 범용성을 보장

 

- Network 상에서 Client와 Server 사이의 통신 방식 중 하나

 

 

 

REST 개념

 

- HTTP URI을 통해 자원을 명시하고 HTTP Method (POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미

 

- REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처를 의미

 

- 웹 사이트 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URL을 부여

 

- CRUD Operation

• Create : 생성 (POST)

• Read : 조회 (GET)

• Update : 수정 (PUT)

• Delete : 삭제 (DELTE)

• HEAD : header 정보 조회 (HEAD)

 

 

 

Richardson Maturity Model (RMM)

 

 

 

레벨 0

 

- 웹의 기본 메커니즘을 사용하지 않는 단계로 HTTP를 통해 데이털르 주고 받지만 모든 데이터 요청 및 응답과 관련한 정보를 HTTP의 Body정보를 활용

 

POST /appointmentService HTTP/1.1

[various other headers]

<openSlotRequest date = "2010-01-04" doctor = "mjones"/>

 

- POX (Plain Old XML)로 요청과 응답을 주고받는 RPC 스타일 시스템으로 HTTP Method는 POST만 사용하며 특정 서비스를 위해 클라이언트에서 접근할 Endpoint는 하나

 

 

 

레벨 1 - 리소스

 

- RMM에서 REST를 위한 첫 단계는 리소스를 도입하는 것으로 모든 요청을 단일 서비스 Endpoint로 보내는 것이 아니라 개별 리소스와 통신

 

POST /doctors/mjones HTTP/1.1

[various other headers]

<openSlotRequest date = "2010-01-04”/>

 

- 즉 함수를 호출하고 인자들을 넘기는 것이 아니라 다른 정볼르 위해 인자들을 제공하는 특정 리소스로 요청을 보냄

 

- 이럴 경우 이점은 자원이 외부에 보여지는 방식과 내부에 저장되는 방식을 분리할 수 있다는 것

 

- 예를 들어 클라이언트 단에서 완전히 다른 포맷으로 저장하더라도 JSON 형태의 데이터를 요청할 수 있음

 

 

 

레벨 2 - HTTP Method

 

- 레벨 1의 URL + HTTP Method 조합으로 리소스를 구분하는 것으로 응답상태를 HTTP Status code를 활용 (현재 가장 많은 RESTful API 이 단계를 제공)

 

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1

Host: royalhope.nhs.uk

 

- 발생한 에러의 종류를 커뮤니케이션하기 위해 상태코드(Status Code)를 사용하는 것, 그리고 안전한 오퍼레이션 (GET 등)과 안전하지 않은 오퍼레이션 간의 강한 분리를 제공하는 것이 레벨 2의 핵심 요소

 

- Status Code를 사용한다는 것은 기존에는 유저 생성 요청을 했을 경우 302 등의 리다이렉트 요청을 서버에서 내려주는 방식이었다면 지금은 201(created)로 유저 생성 성공을 알릴 뿐 페이지 이동은 Client 단에서 해결하는 방식 (Login의 경우 성공은 200, 실패시 인증실패는 401, 성공했으나 권한 문제는 403 등)

 

- 즉 서버는 순수하게 API로서의 기능만 제공하게 되는 것 (View는 Client에서)

 

- 강한 분리를 제공하는 것은 HTTP에서 GET은 멱등박식으로 자원을 추출하는데 이에 어떤 순서로든 얼마든지 호출하든 매번 같은 결과를 얻도록함 (이에 통신상의 모든 참여자에게 캐싱 기능을 지원하는 다양한 방법을 제공)

 

 

 

레벨 3 - 하이퍼미디어 컨트롤

 

- HATEOAS (Hypertext As The Engine Of Application State) 애플리케이션 상태 엔진으로서의 하이퍼 미디어

 

- 하이퍼 미디어란 하나의 컨텐츠가 텍스트나 이미지, 사운드와 같은 다양한 포맷의 컨텐츠를 링크하는 개념

 

- 이것은 관련 컨텐츠를 보기위해 링크를 따라가는 방식과 유사한 방식으로 동작하는데, 클라이언트가 다른 자원에 대한 링크를 통해 서버와 (잠재적으로 상태 변이를 초래하는) 상호작용을 함

 

- 즉 특정 API를 요청한 후 다음 단계로 할 수 있는 작업을 알려주는 것이며 다음 단계의 작업을 위한 리소스의 URL을 알려주는 것

 

- 이 단계를 적용하면 클라이언트에 영향을 미치지 않으면서 서버를 변경하는 것이 가능

 

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1

Host: royalhope.nhs.uk

 

HTTP/1.1 200 OK

[various headers]

<openSlotList>

<slot id = "1234" doctor = "mjones" start = "1400" end = "1450">

            <link rel = "/linkrels/slot/book"

            uri = "/slots/1234"/>

</slot>

<slot id = "5678" doctor = "mjones" start = "1600" end = "1650">

            <link rel = "/linkrels/slot/book"

            uri = "/slots/5678"/>

</slot>

</openSlotList>

 

- 단점은 클라이언트가 수행할 작업을 찾기 위해 링크를 따라가기 때문에 컨트롤 탐색에 꽤 많은 호출이 발생할 수 있다는 것

 

- 또한 복잡성이 증가할 수 있으며 HTTP 요청상에 나타나는 부하로 낮은 지연시간이 요구될 때 문제가 될 수 있음

 

- HTTP 기반의 REST 페이로드는 JSON 또는 바이너리 등의 포맷을 지원하므로 실제로 SOAP보다 훨씬 간결할 수 있지만 쓰리프트와 같은 바이너리 프토토콜에는 상대가 되지 못함

 

- 또한 웹 소켓의 경우 HTTP 초기 핸드세이크 후에 클라이언트와 서버 간에 TCP 접속이 이루어지고 브라우저에서 스트림 데이터를 보낼 때 효율적일 수 있음

 

- 따라서 HTTP가 대규모 트래픽에는 적합할 수 있지만 TCP 또는 다른 네트워킹 기술 기반의 프토콜과 비교하면 낮은 지연시간이 필요한 통신에는 그다지 좋은 선택이 아닐 수 있음

 

- 이러한 단점에도 HTTP 기반의 REST는 서비스 대 서비스의 상호작용을 위한 합리적이고 기본적인 선택

 

 

 

REST 구성 요소

 

1. 자원 (Resource) : URL

 

- 모든 자원에 고유한 ID가 존재하고 이 자원은 Server 존재

 

- 자원을 구별하는 ID는 ‘/group/:group_id’ 와 같은 HTTP URL

 

- Client는 URL을 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청

 

 

2. 행위 (Verb) : HTTP Method

 

- HTTP 프로토콜의 Method를 사용

 

- HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 Method를 제공

 

 

3. 표현 (Representation of Resource)

 

- Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답을 보냄

 

- REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등의 여러 형태의 표현으로 나타낼 수 있음

 

- JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적

 

 

 

REST의 특징

 

1. Server-Client (서버-클라이언트 구조)

 

- 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client

• REST Server : API를 제공하고 비즈니스 로직 처리 및 저장을 책임

• Client : 사용자 인증이나 Context(세션, 로그인 정보) 등을 직접 관리하고 책임

 

- 상호간 의존성 줄어듬

 

 

2. Stateless (무상태)

 

- HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 가짐

 

- 무상태성이란 작업을 위한 상태정보를 따로 저장하고 관리하지 않음 (세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API Server는 들어오는 요청만 단순히 처리하면 됨)

 

- Client와 Context를 Server에 저장하지 않음 (세션과 쿠키와 같은 Context 정보를 신경쓰지 않아도 되므로 구현이 단순해짐)

 

- Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리

• 각 API 서버는 Client의 요청만을 단순 처리

• 이전 요청이 다음 요청의 처리에 연관되어서는 안된다는 것 (이전 요청이 DB를 수정하여 DB에 의해 바뀌는 것은 허용)

• Server의 처리방식에 일관성을 부여하고 부담이 줄어들어 서비스 자유도가 높아짐

 

 

3. Cacheable (캐시 처리 기능)

 

- 웹 표준 HTTP Protocol을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 가능

• HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능 적용할 수 있음

• HTTP Protocol 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능

 

- 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구

 

- 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랙잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수  있음

 

 

4. Layered System (계층화)

 

- Client는 REST API Server만 호출

 

- REST Server는 다중 계층으로 구성될 수 있음

• API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하면 구조상의 유연성을 줄 수 있음

• 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있음

 

- Proxy, Gateway 같은 네트워크 기반의 중간 매체를 사용할 수 있음

 

 

5. Self-descriptiveness (자체 표현 구조)

 

- REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있음

 

- Server로부터 스크립트를 받아서 Client에서 실행 

 

- 반드시 사용할 필요 없음

 

 

6. Uniform Interface (인터페이스 일관성)

 

- URL로 지정한 Resource에 대한 모든 조작이 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일

 

- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능 (특정 언어나 기술에 종속되지 않음)

 

 

 

REST의 단점

 

- HTTP 메소드의 한계에 묶임

• REST API는 HTTP 메소드를 이용하여 URL에 대한 행위를 정의하는데 따라서 간단한 수준의 메소드만 지원할 수 있음 (예를 들어 메일을 보낸다라는 행위는 단일 메소드로 구현하기 쉽지않음)

 

- 표준이 없어서 관리하기 어려움

• REST API는 API 설계 가이드일뿐 명시적인 표준이 아님, 따라서 관리가 어렵고 좋은 API 디자인에 대한 가이드가 쉽지 않음, 어떤 가이드는 특정한 REST API에는 맞지만 또 다른 곳에서는 맞지 않을 수 있음

 

- RDMS와의 관계

• REST API를 RDBMS에 적극적으로 사용하기 위해서는 RESTful한 테이블 구조가 필요하게 된는데 이것보다는 NoSQL 쪽이 더 잘 맞는 추세

 

 

 

REST API

 

- HTTP 통신에서 어떤 자원에 대한 CRUD요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식

 

 

 

RESTful

 

- REST API의 설계 의도를 정확하게 지켜주는 API를 RESTful 하다라고 표현

 

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

 

- URL은 자원을 정확하고 인식하기 편하게 표현하는데에 집중하고 지우너에 대한 행위는 Uniform하게 HTTP 메소드를 통해 정의해야함

 

 

참조 URL

 

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://nesoy.github.io/articles/2017-02/REST

https://www.a-mean-blog.com/ko/blog/%ED%86%A0%EB%A7%89%EA%B8%80/_/REST%EC%99%80-RESTful-API

https://meetup.toast.com/posts/92

http://blog.naver.com/PostView.nhn?blogId=complusblog&logNo=220986337770

https://brainbackdoor.tistory.com/53

https://hyunalee.tistory.com/1