REST, RESTful, 그리고 RESTful API

 

REST란?

 

Representational State Transfer : 자원의 상태 전달이며, 일종의 네트워크 아키텍처다.

일반적으로 아래에서 언급되는 6가지의 아키텍처를 잘 지켰느냐에 따라 Restful하다, REST API라고 말한다.

 

 

RESTful API 설계를 위한 6개의 핵심 아키텍처

 

1. Client - Server
   - Client와 Server가 서로 분리되어야 하며, 서로 독립적으로 개발되어야한다.
   - 자원이 있는 쪽을 Server라 칭하며, 자원을 요청하는 쪽이 Client가 된다.
   - REST서버는 API를 제공하고 클라이언트는 사용자 인증에 관련된 일들을 직접 관리한다.
2. Stateless
   - 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않는다.
   - REST API는 Stateless이다. 즉, 상태 정보를 유지하지 않는다.
   - 각각의 요청은 서로 독립적으로 만들어지며, 각 요청은 해당 요청을 완성시키는데 필수적인 데이터를 가지고 있다.
   - 이전 요청이 다음 요청 처리에 연관이 되면 안된다.
3. Cache 
   - 클라이언트는 서버의 응답을 Cache(임시저장) 할 수 있어야 한다. 
   - 클라이언트가 Cache를 통해서 응답을 재사용할 수 있어야 하며, 이릍 통해 서버의 부하를 낮춘다.
   - Stateless API는 대량의 수신 및 아웃바운드 호출을 처리하여 요청 오버헤드를 증가시킬 수 있기 때문에, REST API는 캐시 사용 가능한 데이터의 저장을 장려하도록 설계되어야 한다.
4. Uniform Interface (인터페이스 일관성)
   - 인터페이스의 일관성을 지키고, 아키텍처를 단순화시켜 작은 단위로 분리하여 클라이언트, 서버가 독립적으로 개선 될 수 있어야 한다.
   - 서버로부터 클라이언트를 분리하기 위한 핵심은 균일한 인터페이스를 갖는 것이다.
   - 균일한 인터페이스란 애플리케이션의 서비스, 모델 및 동작이 API 계층 자체에 밀접하게 결합되지 않고 애플리케이션의 독립적 진화를 가능하게 하는 통일된 인터페이스를 갖는 것이다.
5. Layered System (계층화)
   - 서버와 클라이언트 사이에 방화벽, 게이트웨이, Proxy 등 다양한 계층 형태로 구성이 가능해야하며, 이를 확장 할 수 있어야 한다.
   - REST API는 서로 다른 아키텍처 계층이 함께 작동하여 보다 확장성이 뛰어나고 모듈식 애플리케이션을 만들 수 있는 계층을 구축한다.
6. Code on Demad (Optional)
   - 자바 애플릿, 자바스크립트 등 특정한 기능을 서버로 부터 클라이언트가 전달받아 코드를 실행 할 수 있어야 한다.
   - 코드 온 디맨드(Code on Demand)는 응용프로그램 내에서 사용하기 위해 API를 통해 코드 또는 애플릿을 전송할 수 있도록 한다.

 

위의 6가지 중 1~5번은 HTTP에 해당되는 내용이며, 6번은 (주로) JavaScript에 해당되는 내용이다.

 

REST, RESTful하다

 

위에 언급된 6가지와 더불어, 다음의 인터페이스 일관성이 잘 지켜져있는지에 따라 REST를 잘 사용했는지를 판단 할 수 있다.

 

 

1. 자원의 식별

 

웹 기반의 REST에서는 리소스 접근을 할 때 URI를 사용한다.

이 URI에 자원을 식별할 수 있는 정보가 들어있어야 한다.

 

ex : https://foo.co.kr/user/100

Resource : user

식별자 : 100

 

 

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

 

요약하자면 리소스 자체를 전달하는 것이 아닌, 리소스의 메세지를 전달한다.

이로인해 클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경, 삭제할 수 있는 충분한 정보를 가지고 있는 것이다.

 

웹에서는 다양한 방식으로 데이터를 전달할 수 있다. 대표적으로 HTML, XML, JSON, TEXT등이 있다.

이중에 어떠한 타입의 데이터인지를 알려주기 위해 HTTP Header 부분에 Content-type을 통해서 데이터의 타입을 지정해줄 수 있다.

또한 리소스 조작을 위해서 데이터 전체를 전달하지 않고, 이를 메세지로 전달한다. 

 

 

3. 자기 서술적 메세지

 

요청하는 데이터가 어떻게 처리 되어져야 하는지 충분한 데이터를 포함할 수 있어야 한다.

 

HTTP기반의 REST에서는 HTTP Method와 Header 정보, 그리고 URI에 포함되는 정보로 표현할 수 있다.

 

	기존 게시판	RESTful API를 지원하는 게시판
글 읽기	GET/list.do?no=510&name=user	GET/list/user/100
글 등록	POST/insert.do	POST/list/user
글 삭제	GET/delete.do?no=510&name=java	DELETE/list/user/100
글 수정	POST/update.do	PUT/list/510

 

예를들어 기존에는 GET,POST로만 자원에 대한 CRUD를 처리하며, URI는 Action(행위)을 나타냈다.

RESTful API는 GET,POST외에 DELETE, PUT를 포함한 4가지 메서드를 모두 사용하여 CRUD를 처리하며, URI는 제어하려는 자원, 즉, 대상을 나타낸다 

 

 

4. Application 상태에 대한 엔진으로써 하이퍼미디어

 

REST API를 개발할 때 단순히 Client 요청에 대한 데이터만 응답해주는 것이 아닌, 관련된 리소스에 대한 Link 정보까지 같이 포함되어야 한다.

 

단, 이 부분은 현업에서 그리 많이 사용하지 않고 있다. 리소스에 대한 Link 정보까지 넘겨주는 과정에서, 불필요한 정보까지 넘겨줄 수 있기 때문이다.

 

 

이러한 조건들을 잘 갖춘 경우, RESTful하다고 표현하고, 이를 REST API라고 부른다.

 

 

SOAP과 REST의 차이

 

글을 보기전에 SOA 아키텍쳐와와 MSA 아키텍쳐의 차이를 이해할 수 있도록 아래 글을 보고 오길 추천한다.

Monolithic, SOA, 그리고 MSA

 

SOAP과 다르게, REST는 XML 사용에만 제한되지 않고 JSON, YAML 외에 기타 다른 데이터 형태를 반환 가능하다. 이때 데이터의 형태는 클라이언드의 요청에 따라 다르다. 또한 RPC(Remote Procedure Call : 원격 프로시저 호출)와 다르게, 사용자는 절차의 명칭과 특정 명령의 특정 파라미터 값을 알 필요가 없다.

 

 

RESTful API의 단점

 

RESTful API의 단점 중 하나는 세션 내에서와 같이 REST의 상태를 유지하는 기능이 손실될 수 있다는 점이다. 또한 새로운 개발자들이 더 사용하기 어려울 수 있다.

 

 

---

 

REST 개념의 이해를 돕는 블로그 글

 

• REST API란 무엇일까?

https://ktko.tistory.com/entry/REST-API란-무엇일까

REST API란 무엇일까?

 

• REST API와 RESTful API

velog.io/@stampid/REST-API%EC%99%80-RESTful-API

REST API와 RESTful API

 

• REST란? REST API란? RESTful이란? 

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

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog

 

• REST API 제대로 알고 사용하기

meetup.toast.com/posts/92

REST API 제대로 알고 사용하기 : NHN Cloud Meetup