REST

웹 개발을 하다보면 REST라는 용어를 자주 접하게 될 것이다. REST라는 개념을 이전에 공부한 적이 있었지만 일을 하다보니 개념에 대해 확실히 알아두고 싶어 글로 정리해보려 한다. 이 글에선 REST 란 무엇이고 어떻게 등장하였으며 더 나아가 RESTful, REST API 까지 알아볼 것이다.

---

REST

REST는 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개되었다.

현재의 아키텍쳐가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단했기 때문에, 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐를 소개했는데 그것이 바로 REST(Representational safe transfer)이다.

REST 구성

• 자원 (Resouce) - URI
• 행위 (Verb) - HTTP Method
• 표현 (Representations) - JSON(반드시 JSON 일 필요는 없지만, 가장 흔하게 쓰인다)

이름이 Terry인 사용자를 생성한다 를 REST 형태로 호출하면

HTTP POST, <http://myweb/users/>
{
	"name":"Terry"
}

// 자원 - <http://myweb/users/>
// 메소드 - POST
// 표현 - { "name" : "Terry" }

REST의 자원

REST는 자원 지향 아키텍처 스타일이라는 정의 답게 모든 것을 자원 즉, 명사로 표현을 하며, 각 세부 자원에는 id를 붙인다.

사용자라는 자원 타입을 http://myweb/users 라고 정의했다면,

terry라는 id를 갖는 리소스는 http://myweb/users/terry 라는 형태로 정의한다.

REST의 자원은 명사의 형태를 띄운다. 따라서 되도록 자원 기반의 명사 형태로 정의하는 것이 REST 형태의 디자인이 된다.

REST의 특징

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

REST는 HTTP 표준에만 따른 다면, 어떠한 기술이라도 사용 가능한 인터페이스 스타일이다.

예를 들어 HTTP + JSON으로 REST API를 정의했다면, 안드로이드 플랫폼이건, iOS 플랫폼이건, 또는 C나 Java/Python이건 특정 언어나 기술에 종속 받지 않고 HTTP와 JSON을 사용할 수 있는 모든 플랫폼에 사용이 가능한 느슨한 결합(Loosely coupling) 형태의 구조이다.

2. Stateless (무상태성)

HTTP는 Stateless Protocol 이므로, REST 역시 무상태성을 갖는다.

상태가 없다라는 뜻은 사용자나 클라이언트의 컨텍스트를 서버 쪽에 유지하지 않는다는 의미로, 쉽게 말해 HTTP Session과 같은 컨텍스트 저장소에 상태 정보를 저장하지 않는 형태를 의미한다.

별도로 상태 정보를 저장하지 않으면 각 API 서버는 들어오는 요청만을 메세지로만 처리하면 된다. 결과적으로 세션과 같은 컨텍스트 정보를 신경쓸 필요가 없어 구현이 단순해진다.

3. Cacheable (캐싱 처리)

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

HTTP 프로토콜 기반의 로드밸런서(mod_proxy)나, SSL은 물론이고 HTTP가 가진 가장 강력한 특징 중의 하나인 캐싱 기능을 적용할 수 있다.

일반적인 서비스에서 조회 기능이 주로 사용됨(60~80%)을 감안하면, HTTP 리소스들을 웹 캐쉬 서버 등에 캐싱하는 것은 용량이나 성능 면에서 이점이 있다. 캐싱 구현은 HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 가능하다.

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

REST API는 동사[ Method ] + 명사[ 자원(URI) ] 로 이루어져 있어서 API 메세지 자체만 보고도 무슨 행위를 하는 API 인지 유추할 수 있다.

메시지 포맷 역시 JSON을 이용해서 직관적으로 이해가 가능한 구조로, REST API 메시지만 보고도 이를 쉽게 이해할 수 있다.

대부분의 REST 기반의 OPEN API들이 API 문서를 별도로 제공하고 있지만, REST의 디자인 사상을 따른 다면 문서의 도움을 최소한으로 받고 API 자체를 이해할 수 있어야 한다.

5. Client - Server 구조

REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보 등)을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.

6. 계층형 구조

API 서버는 순수 비지니스 로직을 수행하고, 그 앞단에 사용자 인증, 암호화(ssl), 로드밸런싱 등을 하는 계층을 추가하여 구조상의 유연상을 둘 수 있다. 이는 간단하게는 HA Proxy나 Apache의 Reverse Proxy를 통해, 더 나아가서는 API gateway 등을 활용하여 Micro Service Architecture로도 구현이 가능하게 한다.

결론은 REST는 웹의 독립적 진화를 위한 분산 시스템 아키텍처 스타일이라고 정의할 수 있겠다.

RESTful

RESTful 하다는 것은 위에서 설명한 REST의 제약 조건을 모두 만족한다는 것이다.

REST API

REST의 특징을 지키는 API를 의미한다. (RESTful API)

---

마치며

REST의 등장은 웹 기술 진화에 큰 영향을 미쳤다. 우리가 프론트엔드와 백엔드로 나누어질 수 있는 이유라고도 볼 수 있을 것 같다(어디까지나 내 생각이다)

REST는 웹 서비스를 구축하고 사용하기 쉽기 때문에 웹 서비스를 구축하기 위한 사실상의 표준이 되어가고 있고 RESTful 웹 서비스를 빠르게 지원하기 위한 많은 프레임워크와 라이브러리가 나왔다.

이처럼 웹 서비스의 핵심적인 기술인 만큼 그 개념을 제대로 알아두길 바란다.

---

참고 자료

- https://brainbackdoor.tistory.com/53

- https://linked2ev.github.io/devlog/2019/10/06/WEB-REST-is-the-independent-evolution-of-the-web/

- https://bcho.tistory.com/953

- https://ko.wikipedia.org/wiki/REST