REST하게 만든 API를 RESTful API라고 한다.
마치 단호박을 달달한 호박이라고 하는 것과 같은 이 무책임한 설명을 납득시키기 위해 먼저 REST가 무엇인지를 간략히 알아보자.
REST의 의미
RESTful의 의미를 알아보기 전에 먼저 REST가 무엇인지를 간략히 알아보자. REST는 Representational State Transfer의 약어로써, HTTP의 설계자 중 한 명이었던 로이필딩(Roy T. Fielding)이 "어떻게 하면 기존 웹의 호환성을 지키면서 http를 발전시킬 수 있을까"를 고민하면서 2000년에 박사논문으로 출시한 아키텍처 스타일이다.
RESTful한 API, RESTful API
맨 처음 말한 호박 같은 설명을 다시 얘기하자면, REST 아키텍처 스타일을 따르는 API를 RESTful API라고 한다. 아키텍처 스타일은 '~~하지마라', '~~해야만 한다' 와 같은 제약조건을 말하는데, REST에서 말하는 모든 REST 스타일을 지켜야만 진정한 의미의 RESTful API라고 말할 수 있다.
- client-server(클라이언트-서버 구조)
- stateless(상태없음)
- cache(캐시 처리 가능)
- uniform interface(인터페이스 일관성)
- layered system(계층화)
- code-on-demand(서버가 네트워크를 통해 클라이언트에 전달한 프로그램을 클라이언트가 실행할 수 있어야 함 *optional)대체로 인터넷에 떠돌아다니는 RESTful API는 다음과 같은 최소한의 가이드라인을 말하기도 하지만, 로이필딩은 이처럼 REST 스타일을 모두 지키지 않은 API를 RESTful API라고 칭해서는 안 된다고 말하고 있다.
- 리소스 중심의 API 디자인 구성
- HTTP 메서드를 기준으로 API 작업 정의
- HTTP 의미 체계 준수
진정한 의미의 RESTful API
위 6가지 REST 아키텍처 스타일은 대체로 http만 따라도 잘 지켜지기 때문에 대체로 오늘날 RESTful API라고 부르는 대부분의 API는 RESTful하게 지켜지고 있다. 하지만 그럼에도 uniform interface를 만족시키는 API는 흔치 않다. uniform interface은 4가지의 아키텍처 스타일로 이루어져 있는데, 여기서 Self-descriptive(자체 표현구조)와 HATEOAS(애플리케이션의 상태는 Hyperlink를 통해 항상 전이 되어야 한다)가 지켜지지 못하고 있다.
따라서 custom media type이나 profile link relation와 같은 방법으로 Content-Type에 미디어타입을 정의함으로써 명세를 참조하여 메시지를 온전히 해석할 수 있도록 만들어야 하고,
API의 HTTP 헤더나 본문에 링크를 담아 HATEOAS를 만족시킨 것이 진정한 의미의 RESTful API라고 볼 수 있다.
꼭 그렇게까지 지켜야만 할까?
uniform interface의 목적은 독립적 진화에 있다. 독립적 진화란 서버의 기능이 변경되어도 클라이언트가 업데이트할 필요가 없는 것을 하는데, 이는 '어떻게 하면 기존 호환성을 지키며 발전할 수 있을까'라는 REST의 목적과 귀결된다.
그런데 꼭 REST하게 만들어야만 할까? 분명 독립적 진화라는 말은 달콤하지만, 이를 달성하기 위해서는 많은 시간과 노력이 필요하다. 따라서 독립적 진화에 관심이 없다면 꼭 REST를 지킬 필요는 없다는 것이 로이필딩의 생각이다. 다만 오랜 시간 동안 진화하는 시스템을 설계하고 싶다면 REST에 대해 좀 더 관심을 가져야 할 것이다.
참고사이트 그런 REST API로 괜찮은가, RESTful API 설계 가이드, RESTful web API 디자인
