TL;DR

여태껏 서비스 API 서버를 개발하면서 RESTful API 를 사용해 왔다. 더 정확하게 표현하자면 GET, POST, PUT 등 HTTP Method 와 Endpoint 를 이용해 API 의 용도를 구분하는 방법론 정도로 취급하고 사용해 왔다고 볼 수 있다. REST 의 약자도 기억하지 못하는 상황에서 내가 RESTful 하다고 생각한 API 가 실제로 RESTful 의 의도에 맞게 사용하고 있는지, 방법론 개발자의 의도를 넘어 어떤 사용방식이 서비스에 좋은 영향을 미칠 지 알아보고자 한다.

RESTful 을 먼저 공부하고 앞의로의 활용을 고민하기 위해 아래와 같이 2개의 포스트로 나누어 작성해 보고자 한다.

RESTful 은 왜 사용하는 것일까?
RESTful API 는 어떻게 사용하는 것이 좋을까?

RESTful 의 역사

REST 는 Representational State Transfer 의 약자로 리소스를 대표하는 상태의 전이를 나타낸다고 볼 수 있다. 웹 서비스를 구성하는 아키텍처 방식 중 하나이다. 하지만 REST 라는 아이디어가 처음 등장했을 때와 현재의 사용 추세는 좀 다른 편인데 자세히 살펴보자.

2000년 - Roy Fielding 의 논문

REST 의 개념은 Roy Fielding 의 박사논문 Architectural Styles and the Design of Network-based Software Architectures 에서 처음 제안되었다. 해당 논문에 대해서는 아래에서 더 자세히 살펴보자.

2000년 이후 - 웹서비스 및 API 개발

RESTful 아키텍처는 웹 서비스와 웹 API 개발에서 점차 더 많이 사용되기 시작되었다고 한다. 이 아키텍처는 HTTP의 간결한 디자인과 함께 자원을 표현하고 상태를 전달하는데 효과적이라는 이점을 제공했다.

2007년 - RESTful 용어 확산

RESTful 이라는 용어는 이 시기에 웹 서비스 및 API 개발 커뮤니티에서 널리 사용되기 시작했다. 물론 국내가 아닌 외국 커뮤니티 인 것으로 보인다.

현재 - RESTful 웹서비스 및 API

현재, RESTful 웹 서비스 및 API는 웹 개발의 중요한 부분이며, 웹 애플리케이션과 서비스 간의 통신에 일반적으로 사용되고 있다. 물론 GraphQL 등 대안이 있지만 아직은 RESTful 을 더 많이 채택하고 있는 것으로 보인다.

Roy Fielding 의 논문에서의 REST

상기했듯 Roy Fielding 의 논문 Architectural Styles and the Design of Network-based Software Architectures 은 웹 아키텍처의 기반 원칙을 정하고 REST 개념을 제시했다. 역사에서 다뤘듯 현재까지 큰 영향을 주고 있는 논문이라 할 수 있다. 해당 논문은 아래의 원칙을 제시한다.

Resource

모든것은 자원(웹페이지, 이미지, DB 등)으로 표현
자원은 고유한 식별자(URI) 로 식별

Representation

자원의 상태는 하나 이상의 표현으로 나타낼 수 있다.
HTML, XML, Json 등

Stateless

REST 시스템은 상태를 서버에 저장하지 않고 클라이언트의 요청에 의해서만 자원의 상태를 변경
이러한 특성은 서버와 클라이언트 간 독립성은 유지시켜줌

Integrated Interface

RESTful 서비스는 단순하고 일관된 인터페이스를 사용해 자원에 접근할 수 있어야 함
HTTP 의 메소드(GET, POST 등) 를 이용한 CRUD 가 대표적이다.

Self Descriptive

API가 자체적으로 메타데이터를 제공하여 클라이언트가 API와 상호작용할 수 있는 방법을 이해할 수 있도록 하는 것을 의미
예를 들어, API 응답의 헤더나 본문에는 어떤 데이터 형식을 사용하고, 어떤 인증 방법을 사용해야 하는지와 같은 정보가 포함
이러한 정보를 통해 클라이언트는 API를 쉽게 이해하고 사용할 수 있으며, API의 변경에 유연하게 대응할 수 있게됨

HATEOAS (Hypertext as the Engine of Application State)

RESTful API의 핵심 원칙 중 하나로, 클라이언트에 의해 이해되고 활용 가능한 하이퍼미디어 링크를 리소스와 함께 반환하는 개념
예를 들어, 클라이언트가 리소스를 요청하면 API는 그 리소스와 함께 다음으로 취할 수 있는 동작 또는 다른 관련 리소스에 대한 링크를 반환
이를 통해 클라이언트는 API와의 상호작용을 탐색하며, 동적으로 리소스를 찾고 조작할 수 있음

RESTful 은 왜 사용하는 것일까?

Roy Fielding 의 논문을 통해 RESTful 이 무엇이고 어떤 개념과 원칙을 제시하는 지 살펴봤다. 이제 이러한 원칙을 지켜서 얻을 수 있는 이점이 무엇인지 살펴보자.

단순성(Simplicity)

HTTP 메서드(GET, POST, PUT, DELETE)를 사용하여 리소스에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행하기 때문에 직관적이고 이해하기 편하다는 것이다. REST 자체가 단순성을 추구하기 때문에 적어도 REST 를 사용하는 API 는 이해하기 쉬울 가능성이 높다. 물론 원칙을 생각하지 않고 사용한다면 REST 를 사용한다고 하지만 복잡할 소지는 있다.

확장성(Scalability)

RESTful 서비스는 분산시스템을 제공하기 용이한 아키텍처라고 할 수 있다. 현대에는 서버와 클라이언트가 분리된 분산 시스템이 일반적이지만, 과거 웹 프레임워크 기반 서비스는 그러지 못했다. MVC 아키텍러를 사용하는 Spring, Django 등이 대표적인데, 클라이언트와 서버가 병합되어 있고 정적이다. 서버가 죽으면 클라이언트 페이지 또한 볼 수 없었다. RESTful 이 도입되고 분산처리 시스템이 일반화 되면서 병렬처리가 용이해진것도 특징이다.

미디어 타입 다양성

RESTful 서비스는 크라이언트와 서버간 다양한 미디어 타입을 교환할 수 있으며 서로간 약속에 의해 클라이언트는 원하는 양식을 서버에 요구할 수 있다.

강한 캐싱 지원

HTTP Cache 를 이용해 클라이언트, 서버 간 효율적인 데이터 교환이 가능하다. HTTP Cache 는 다음 기회에 자세하게 다뤄보자. 이를 이용해 네트워크 트래픽을 줄이고 응답시간을 단축할 수 있다.

독립적인 클라이언트와 서버

확장성과 궤를 같이하는 이 특징은 서버, 클라이언트를 각각 매우 발전시키는데 큰 영향을 미쳤다고 생각하고 있다. 클라이언트는 점점 단순 웹페이지를 벗어나 하나의 Application 으로 발전하고 있고, 서버도 클라이언트에서 벗어나 최적화 되고 발전하고 있다.

대중적인 지원

HTTP Protocol 을 사용한다는 점 때문에 진입장벽이 낮아 대중적으로 많이 사용될 수 있었다.

플랫폼 독립성

어떠한 플랫폼 에서도 사용할 수 있다는 점이 시스템의 확장성에 기여한다고 볼 수 있다.

보안

HTTPS 의 무결성의 덕택으로 RESTful 은 비교적 안전하게 이용할 수 있다.